CPU load spikes affecting performance introduced in hrev46690

[jstressman]

Up to and including hrev46689 my system would idle at almost flatline. Between 0 and 2% or so on any core. But starting with Pawel's changes in hrev46690 my CPUs will randomly spike to almost full load every few seconds, for anywhere from a fraction of a second to a couple seconds, during which time the system basically partially freezes. You can usually move the mouse, but the menus are frozen, displays like the ActivityMonitor freeze and then jump ahead when it unfreezes (which you'll see as the jagged sawtooth pattern on the screenshot).

I'd noticed this a few days ago when I finally updated my system from hrev46677, which was the last normal nightly release that worked for me. While trying to track down another boot problem that was introduced between that and the next nightly, I noticed that this issue was introduced in the same revision.

[jstressman]

performance from hrev46690 and on to the current nightlies, with hrev48579 being the most recent I've tested.

[jstressman]

The boot up bug I was researching (that was also introduced in hrev46690) when I tracked this one down is in #11020 for reference.

[jstressman]

performance up to and including hrev46689

[jstressman]

I blacklisted the cpuidle module in add-ons/kernel/power/cpuidle and this problem (along with my boot problem in #11020) disappeared.

While the cpu usage is higher than it was before hrev46690, it's perfectly usable and barely noticeable compared to this bug's behavior.

Attaching a screenshot from hrev48579 while running with cpuidle blacklisted to compare with the hrev48579 above without it blacklisted.

[jstressman]

hrev48579 with cpuidle blacklisted

[accessays]

Not sure if related, but I've been experiencing something similar running Haiku in VMware. Every once in a while (5 mins to half an hour) CPU usage would spike to 100% and stay around there for several seconds and then go back to ~0%. This might be related to VMware itself tho, as pausing Haiku and then resuming usually fixes the problem. I have experienced this with hrev52001 and hrev52000, gcc2 hybrids.

[waddlesplash]

Is this still a problem, after the intervening scheduler, power, and kernel synchronization primitives fixes over the years since?

[jstressman]

I don't have a way to check as I finally retired that computer a year or two ago. Probably safe to retire this one and if someone actually runs into the problem we can reopen it or open a new one.