linux-kernel - Re: [PATCH] intel_idle: Add RaptorLake support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <76cac4882fe1444bb381825e18224592656f10d4.camel@intel.com>
Date: Mon, 8 Apr 2024 02:01:43 +0000
From: "Zhang, Rui" <rui.zhang@...el.com>
To: "peter.laszlo2@...il.com" <peter.laszlo2@...il.com>
CC: "lenb@...nel.org" <lenb@...nel.org>, "jacob.jun.pan@...ux.intel.com"
	<jacob.jun.pan@...ux.intel.com>, "smarter3@...il.com" <smarter3@...il.com>,
	"Kumar, Vinay" <vinay.kumar@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "noltari@...il.com" <noltari@...il.com>,
	"Bityutskiy, Artem" <artem.bityutskiy@...el.com>, "linux-pm@...r.kernel.org"
	<linux-pm@...r.kernel.org>
Subject: Re: [PATCH] intel_idle: Add RaptorLake support

On Sun, 2024-04-07 at 19:37 +0200, László Péter wrote:
> 
> 
> > On 20 Aug 2023, at 11:20, Zhang, Rui <rui.zhang@...el.com> wrote:
> > 
> > This is still work in progress because there are still some open
> > questions that we cannot answer from our measurement, and the table
> > is
> > not finalized yet.
> > 
> > thanks,
> > rui
> > 
> > 
> 
> Hi,
> 
> I also just stumbled upon this patch series as I was wondering about
> the lack of specific support for RaptorLake in intel_idle. The
> AlderLake specific part of the intel_idle.c code mentions that "On
> AlderLake C1 has to be disabled if C1E is enabled, and vice versa ….
> By default we enable C1E and disable C1 by marking it with...”.  
> Without a patch on RaptorLake (which I assume works the same way)
> this cannot be controlled with the preferred_cstates kernel
> parameter.

That is true, but that only applies when you have a custom table which
expose C1 and C1E as two separate states.

The default behavior (intel_idle + _CST c-states) doesn't have this
issue. We will just follow the system default.

>  Also on my NUC 13 Pro i5-1340P the latency for C10 looks
> suspiciously large compared to the AlderLake cstates table.

Does this bring any real issue in your case?

We do have finished a series of evaluation on RPL, but we didn't find
obvious PnP benefit by introducing a custom table. That is why we
stopped shipping one for RPL.

If you find any real case that this impacts, it would be nice to share
your proposal and test data.

thanks,
rui