Received-SPF: pass (google.com: domain of linux-kernel+bounces-162079-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
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
In-Reply-To: <87zftcy0xt.fsf@somnus>
References: <Zgtjdd0C2FzYVBto@xsang-OptiPlex-9020> <87zfth3l6y.fsf@somnus>
 <CAJZ5v0g_GKF8-QK5UdFCpJapf+MK7EouQ7hMTVtPYRjNNyUt+g@mail.gmail.com>
 <3aba1a1d-8ebc-4ee0-9caf-d9baae586db7@arm.com> <87zftcy0xt.fsf@somnus>
Date: Mon, 29 Apr 2024 12:40:52 +0200
Message-ID: <87sez4xxhn.fsf@somnus>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Anna-Maria Behnsen <anna-maria@linutronix.de> writes:

> 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=E2=80=AFAM 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.
>>>=20
>>> You can look at the "usage" and "time" numbers for idle states in
>>>=20
>>> /sys/devices/system/cpu/cpu*/cpuidle/state*/
>>>=20
>>> 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).
>>>=20
>>> 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.
>

Now here are the values of the states and the time because I forgot to
track also the time in the first run:

USAGE		good            bad		bad+patch
		----            ---             ---------
state0          115		137		234
state1          450680		354689		420904
state2          3092092		2687410		3169438


TIME		good            bad		bad+patch
		----            ---             ---------
state0		9347		9683		18378
state1		626029557	562678907	593350108
state2		6130557768	6201518541	6150403441


> 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...

.. but with the time values: CPUs are less often but in total longer in
state2.

Thanks,

	Anna-Maria