From: "Zhang, Rui" <rui.zhang@intel.com>
To: "peter.laszlo2@gmail.com" <peter.laszlo2@gmail.com>
Cc: "lenb@kernel.org" <lenb@kernel.org>,
"jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
"smarter3@gmail.com" <smarter3@gmail.com>,
"Kumar, Vinay" <vinay.kumar@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"noltari@gmail.com" <noltari@gmail.com>,
"Bityutskiy, Artem" <artem.bityutskiy@intel.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH] intel_idle: Add RaptorLake support
Date: Mon, 8 Apr 2024 02:01:43 +0000 [thread overview]
Message-ID: <76cac4882fe1444bb381825e18224592656f10d4.camel@intel.com> (raw)
In-Reply-To: <BCBB0027-F0E9-42EE-BB43-D50091D9115F@gmail.com>
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@intel.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
prev parent reply other threads:[~2024-04-08 2:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 7:02 Álvaro Fernández Rojas
2023-01-19 7:52 ` Zhang, Rui
2023-01-19 13:26 ` Rafael J. Wysocki
2023-01-19 16:13 ` Zhang, Rui
2023-08-19 19:41 ` Guillaume Martres
2023-08-20 9:20 ` Zhang, Rui
2023-08-20 10:28 ` Guillaume Martres
2023-08-24 6:30 ` Zhang, Rui
2024-04-07 17:37 ` László Péter
2024-04-08 2:01 ` Zhang, Rui [this message]
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=76cac4882fe1444bb381825e18224592656f10d4.camel@intel.com \
--to=rui.zhang@intel.com \
--cc=artem.bityutskiy@intel.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=noltari@gmail.com \
--cc=peter.laszlo2@gmail.com \
--cc=smarter3@gmail.com \
--cc=vinay.kumar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®