Re: [PATCH] intel_idle: Add Jasper Lake and Elkhart Lake support

[Kai-Heng Feng]

On Tue, Jul 30, 2024 at 9:59 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Mon, Jul 29, 2024 at 6:08 AM Kai-Heng Feng
> <kai.heng.feng@xxxxxxxxxxxxx> wrote:
> >
> > [+Cc Rafael, Srinivas]
> >
> > On Fri, Jul 26, 2024 at 2:52 PM Zhang, Rui <rui.zhang@xxxxxxxxx> wrote:
> > >
> > > On Fri, 2024-07-26 at 14:26 +0800, Kai-Heng Feng wrote:
> > > > Without proper C-state support, the CPU can take long time to exit to
> > > > C0
> > > > to handle IRQ and perform DMA.
> > >
> > > Can you provide more details?
> > >
> > > Say, what cstate is entered w/ and w/o this patch?
> >
> > Without the patch it's ACPI C1, C2 and C3.
>
> They are called like this because they come from ACPI _CST.  You need
> to use turbostat (or equivalent) to check what C-states really are
> entered.

Both C1, C2 and C3 have some residencies.

>
> >
> > >
> > > can you show the output of "grep .
> > > /sys/devices/system/cpu/cpu0/cpuidle/state*/*" without this patch?
> >
> > /sys/devices/system/cpu/cpu0/cpuidle$ grep . */*
> > state0/above:0
> > state0/below:631
> > state0/default_status:enabled
> > state0/desc:CPUIDLE CORE POLL IDLE
> > state0/disable:0
> > state0/latency:0
> > state0/name:POLL
> > state0/power:4294967295
> > state0/rejected:0
> > state0/residency:0
> > state0/time:19513
> > state0/usage:635
> > state1/above:26
> > state1/below:12437
> > state1/default_status:enabled
> > state1/desc:ACPI FFH MWAIT 0x0
>
> This is C1 AFAICS.
>
> > state1/disable:0
> > state1/latency:1
> > state1/name:C1_ACPI
> > state1/power:0
> > state1/rejected:0
> > state1/residency:1
> > grep: state1/s2idle: Is a directory
> > state1/time:18621370
> > state1/usage:74523
> > state2/above:1690
> > state2/below:17
> > state2/default_status:enabled
> > state2/desc:ACPI FFH MWAIT 0x31
>
> This looks like something that used to be called "C7s".
>
> > state2/disable:0
> > state2/latency:253
> > state2/name:C2_ACPI
> > state2/power:0
> > state2/rejected:0
> > state2/residency:759
> > grep: state2/s2idle: Is a directory
> > state2/time:7063052
> > state2/usage:7909
> > state3/above:13111
> > state3/below:0
> > state3/default_status:enabled
> > state3/desc:ACPI FFH MWAIT 0x60
>
> And this looks like C10.
>
> > state3/disable:0
> > state3/latency:1048
> > state3/name:C3_ACPI
> > state3/power:0
> > state3/rejected:0
> > state3/residency:3144
> > grep: state3/s2idle: Is a directory
> > state3/time:4451519230
> > state3/usage:55467
> >
> >
> > >
> > > >
> > > > The data collect via wult shows the latency is similar to Broxton, so
> > > > use the existing table to support C-state on JSL and EHL.
> > >
> > > so you have done cstate measurement on the EHL using wult?
> > > can you share more details about the measurement results?
> >
> > I look at the "spikes" of the aggregated graph. Not sure if it's the
> > right way to interpret the graph though.
> >
> > It will be much better if Intel can add the proper C-states table for
> > JSL and EHL.
>
> So what's missing in the above, from the technical standpoint?

The crucial part to make the issue (i.e. slow ethernet) is
".disable_promotion_to_c1e = true".

Can we use that for EHL and JSL?

Kai-Heng