lkml.org 
[lkml]   [2020]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ACPI _CST introduced performance regresions on Haswll
From
Date
On 10/6/2020 11:18 PM, Mel Gorman wrote:
> On Tue, Oct 06, 2020 at 09:29:24PM +0200, Rafael J. Wysocki wrote:
>>> After the commit, the default_status file does not appear in /sys
>>>
>> Something is amiss, then, because the commit doesn't affect the presence of
>> this file.
>>
> This was cleared up in another mail.
>
>> The only thing it does is to set the use_acpi flag for several processor
>> models in intel_idle.c.
>>
>> It can be effectively reversed by removing all of the ".use_acpi = true,"
>> lines from intel_idle.c.
>>
>> In particular, please check if changing the value of use_acpi in struct
>> idle_cpu_hsx from 'true' to 'false' alone (without reverting the commit)
>> makes the issue go away in 5.9-rc8 (the default_status file should be
>> present regardless).
>>
> Thanks. I applied the following
>
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index 9a810e4a7946..6478347669a9 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -1044,7 +1044,7 @@ static const struct idle_cpu idle_cpu_hsw __initconst = {
> static const struct idle_cpu idle_cpu_hsx __initconst = {
> .state_table = hsw_cstates,
> .disable_promotion_to_c1e = true,
> - .use_acpi = true,
> + .use_acpi = false,
> };
>
> netperf UDP_STREAM
> pre enable enable 5.9-rc8 5.9-rc8
> cst cst cst-no-hsx-acpi vanilla no-hsx-acpi
> Hmean send-64 203.96 ( 0.00%) 179.23 * -12.13%* 201.04 ( -1.44%) 203.24 ( -0.36%) 233.43 * 14.45%*
> Hmean send-128 403.66 ( 0.00%) 355.99 * -11.81%* 402.28 ( -0.34%) 387.65 * -3.97%* 461.47 * 14.32%*
> Hmean send-256 784.39 ( 0.00%) 697.78 * -11.04%* 782.15 ( -0.29%) 758.49 * -3.30%* 895.31 * 14.14%*
> Hmean recv-64 203.96 ( 0.00%) 179.23 * -12.13%* 201.04 ( -1.44%) 203.24 ( -0.36%) 233.43 * 14.45%*
> Hmean recv-128 403.66 ( 0.00%) 355.99 * -11.81%* 402.28 ( -0.34%) 387.65 * -3.97%* 461.47 * 14.32%*
> Hmean recv-256 784.39 ( 0.00%) 697.78 * -11.04%* 782.15 ( -0.29%) 758.49 * -3.30%* 895.28 * 14.14%*
>
> This is a more limited run to save time but is enough to illustrate
> the point.
>
> pre-cst is just before your patch
> enable-cst is your patch that was bisected
> enable-cst-no-hsx-acpi is your patch with use_acpi disabled
> 5.9-rc8-vanilla is what it sounds like
> 5.9-rc8-no-hsx-acpi disables use_acpi
>
> The enable-cst-no-hsx-acpi result indicates that use_acpi was the issue for
> Haswell (at least these machines). Looking just at 5.9-rc8-vanillaa might
> have been misleading because its performance is not far off the baseline
> due to unrelated changes that mostly offset the performance penalty.
>
> The key question is -- how appropriate would it be to disable acpi for
> Haswell? Would that be generally safe or could it hide other surprises?
>
It should be safe, but let's try to do something more fine-grained.

There is the CPUIDLE_FLAG_ALWAYS_ENABLE flag that is set for C1E.  Can
you please try to set it for C6 in hsw_cstates instead of clearing
use_acpi in idle_cpu_hsx and retest?


\
 
 \ /
  Last update: 2020-10-07 17:47    [W:0.073 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site