[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dbc2892f-0735-4510-9509-b225b65537c9@arm.com>
Date: Wed, 20 Nov 2024 13:06:58 +0100
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Pierre Gondois <pierre.gondois@....com>,
"Rafael J. Wysocki" <rafael@...nel.org>, Hans de Goede <hdegoede@...hat.com>
Cc: Len Brown <lenb@...nel.org>, anna-maria@...utronix.de,
tglx@...utronix.de, peterz@...radead.org, frederic@...nel.org,
corbet@....net, akpm@...ux-foundation.org, linux-acpi@...r.kernel.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
Len Brown <len.brown@...el.com>, Arjan van de Ven <arjan@...ux.intel.com>,
Todd Brandt <todd.e.brandt@...el.com>
Subject: Re: [PATCH v2] ACPI: Replace msleep() with usleep_range() in
acpi_os_sleep().
On 20/11/2024 10:01, Pierre Gondois wrote:
>
>
> On 11/18/24 13:02, Rafael J. Wysocki wrote:
>> Hi Hans,
>>
>> On Mon, Nov 18, 2024 at 12:38 PM Hans de Goede <hdegoede@...hat.com>
>> wrote:
>>>
>>> Hi Rafael, Len,
>>>
>>> On 18-Nov-24 12:03 PM, Rafael J. Wysocki wrote:
>>>> On Sat, Nov 16, 2024 at 12:11 AM Len Brown <lenb@...nel.org> wrote:
[...]
> FWIW, testing the above version on an Arm Juno platform by executing
> the following method:
>
> Method (SLEE, 1, Serialized) {
> Sleep(Arg0)
> }
>
> _wo: without patch
> _w: with patch
> - Values in ns.
> - Requesting to sleep X ms
> - Tested over 10 iterations
> - HZ=250
> +------+------------+----------+------------+---------+-----------+
> | ms | mean_wo | std_wo | mean_w | std_w | ratio |
> +------+------------+----------+------------+---------+-----------+
> | 1 | 8087797 | 2079703 | 1313920 | 55066 | -83.75429 |
> | 2 | 7942471 | 2201985 | 2416064 | 111604 | -69.58044 |
> | 3 | 8373704 | 144274 | 3632537 | 111037 | -56.61970 |
> | 4 | 7946013 | 2214330 | 4606028 | 255838 | -42.03346 |
> | 5 | 11418920 | 1673914 | 5955548 | 131862 | -47.84490 |
> | 6 | 11427042 | 1677519 | 7045713 | 211439 | -38.34176 |
> | 7 | 12301242 | 221580 | 8174633 | 330050 | -33.54628 |
> | 8 | 11411606 | 1672182 | 9191048 | 431767 | -19.45877 |
> | 9 | 16722304 | 1288625 | 10517284 | 103274 | -37.10625 |
> | 10 | 16746542 | 1280385 | 11564426 | 417218 | -30.94439 |
> | 20 | 24294957 | 70703 | 22756497 | 673936 | -6.33243 |
> | 30 | 36284782 | 74340 | 34131455 | 391473 | -5.93452 |
> | 40 | 44703162 | 1199709 | 45407108 | 289715 | 1.57471 |
> | 50 | 56311282 | 281418 | 56098040 | 607739 | -0.37868 |
> | 60 | 64225811 | 247587 | 64302246 | 132059 | 0.11901 |
> | 70 | 76299457 | 99853 | 76282497 | 83910 | -0.02223 |
> | 100 | 104214393 | 38642 | 104212524 | 244424 | -0.00179 |
> | 1000 | 1016131215 | 245725 | 1017051744 | 2748280 | 0.09059 |
> | 2000 | 2007711297 | 1325094 | 2007628922 | 1421807 | -0.00410 |
> +------+------------+----------+------------+---------+-----------+
> - With the patch, the min sleep duration is never below the requested
> sleep duration
>
> So indeed the penalty of using msleep is big for small sleep durations.
Just to make sure, this is with Rafael's proposal, using msleep() for
values >= 48ms = (12 * 1000/250)ms and usleep_range() otherwise?
Powered by blists - more mailing lists