linux-kernel - Re: [linus:master] [timers] 7ee9887703: stress-ng.uprobe.ops_per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87zftcy0xt.fsf@somnus>
Date: Mon, 29 Apr 2024 11:26:22 +0200
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Lukasz Luba <lukasz.luba@....com>, "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Oliver Sang <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev,
 lkp@...el.com, linux-kernel@...r.kernel.org, Thomas Gleixner
 <tglx@...utronix.de>, ying.huang@...el.com, feng.tang@...el.com,
 fengwei.yin@...el.com, Frederic Weisbecker <frederic@...nel.org>, Daniel
 Lezcano <daniel.lezcano@...aro.org>, linux-pm@...r.kernel.org
Subject: Re: [linus:master] [timers] 7ee9887703:
 stress-ng.uprobe.ops_per_sec -17.1% regression

Hi,

Lukasz Luba <lukasz.luba@....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@...utronix.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