From: Anna-Maria Behnsen <anna-maria@linutronix.de>
To: Lukasz Luba <lukasz.luba@arm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Oliver Sang <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com,
Frederic Weisbecker <frederic@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
linux-pm@vger.kernel.org
Subject: Re: [linus:master] [timers] 7ee9887703: stress-ng.uprobe.ops_per_sec -17.1% regression
Date: Mon, 29 Apr 2024 11:26:22 +0200 [thread overview]
Message-ID: <87zftcy0xt.fsf@somnus> (raw)
In-Reply-To: <3aba1a1d-8ebc-4ee0-9caf-d9baae586db7@arm.com>
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
next prev parent reply other threads:[~2024-04-29 9:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 8:39 [linus:master] [timers] 7ee9887703: stress-ng.uprobe.ops_per_sec -17.1% regression kernel test robot
2024-04-01 22:46 ` Frederic Weisbecker
2024-04-02 1:46 ` Oliver Sang
2024-04-04 14:05 ` Frederic Weisbecker
2024-04-25 8:23 ` Anna-Maria Behnsen
2024-04-25 10:15 ` Christian Loehle
2024-04-26 10:15 ` Anna-Maria Behnsen
2024-04-26 11:35 ` Frederic Weisbecker
2024-04-26 15:39 ` Christian Loehle
2024-04-26 6:53 ` Oliver Sang
2024-04-26 16:03 ` Rafael J. Wysocki
2024-04-29 7:53 ` Lukasz Luba
2024-04-29 9:26 ` Anna-Maria Behnsen [this message]
2024-04-29 10:40 ` Anna-Maria Behnsen
2024-04-29 17:02 ` Rafael J. Wysocki
2024-05-02 12:56 ` Anna-Maria Behnsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zftcy0xt.fsf@somnus \
--to=anna-maria@linutronix.de \
--cc=daniel.lezcano@linaro.org \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lukasz.luba@arm.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.