Messages in this thread | | | From | Anna-Maria Behnsen <> | Subject | Re: [linus:master] [timers] 7ee9887703: stress-ng.uprobe.ops_per_sec -17.1% regression | Date | Mon, 29 Apr 2024 11:26:22 +0200 |
| |
Hi,
Lukasz Luba <lukasz.luba@arm.com> writes: > On 4/26/24 17:03, Rafael J. Wysocki wrote: >> On Thu, Apr 25, 2024 at 10:23 AM Anna-Maria Behnsen >> <anna-maria@linutronix.de> wrote:
[...]
>>> So my assumption here is, that cpuidle governors assume that a deeper >>> idle state could be choosen and selecting the deeper idle state makes an >>> overhead when returning from idle. But I have to notice here, that I'm >>> still not familiar with cpuidle internals... So I would be happy about >>> some hints how I can debug/trace cpuidle internals to falsify or verify >>> this assumption. >> >> You can look at the "usage" and "time" numbers for idle states in >> >> /sys/devices/system/cpu/cpu*/cpuidle/state*/ >> >> The "usage" value is the number of times the governor has selected the >> given state and the "time" is the total idle time after requesting the >> given state (ie. the sum of time intervals between selecting that >> state by the governor and wakeup from it). >> >> If "usage" decreases for deeper (higher number) idle states relative >> to its value for shallower (lower number) idle states after applying >> the test patch, that will indicate that the theory is valid. > > I agree with Rafael here, this is the first thing to check, those > statistics. Then, when you see difference in those stats in baseline > vs. patched version, we can analyze the internal gov decisions > with help of tracing. > > Please also share how many idle states is in those testing platforms.
Thanks Rafael and Lukasz, for the feedback here!
So I simply added the state usage values for all 112 CPUs and calculated the diff before and after the stress-ng call. The values are from a single run.
good bad bad+patch ---- --- --------- state0 111 68 234 state1 419774 362549 408681 state2 3184799 2499565 3185723
good: 57e95a5c4117 ("timers: Introduce function to check timer base is_idle flag") bad: v6.9-rc4 bad+patch: v6.9-rc4 + patch
I choosed v6.9-rc4 for "bad", to make sure all the timer pull model fixes are applied.
If I got Raphael right, the values indicate, that my theory is not right...
Thanks,
Anna-Maria
| |