intel_idle: Add RaptorLake support

PATCH In review Álvaro Fernández Rojas 5 participants 10 messages Jan 19, 2023 – Apr 8, 2024 Intel idle driver

lore

Share & tools

lore

Álvaro Fernández Rojas

author

2023-01-19 07:02 UTC #0 lore raw

PATCH 1/1 intel_idle: Add RaptorLake support

This patch adds RaptorLake support to the intel_idle driver.

Since RaptorLake and AlderLake C-state are characteristics the same, we use AlderLake C-states tables for RaptorLake as well.

Signed-off-by Álvaro Fernández Rojas <[email protected]>

---
 drivers/idle/intel_idle.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/idle/intel_idle.c +6 -0

index cfeb24d40d37..1a35b98d9bae 100644
@@ -1429,6 +1429,9 @@ static const struct x86_cpu_id intel_idle_ids[] __initconst = {
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE,		&idle_cpu_adl),
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L,		&idle_cpu_adl_l),
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_N,		&idle_cpu_adl_n),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE,		&idle_cpu_adl),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_P,	&idle_cpu_adl_n),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_S,	&idle_cpu_adl),
 	X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X,	&idle_cpu_spr),
 	X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL,	&idle_cpu_knl),
 	X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,	&idle_cpu_knl),

@@ -1867,6 +1870,9 @@ static void __init intel_idle_init_cstates_icpu(struct cpuidle_driver *drv)
 	case INTEL_FAM6_ALDERLAKE:
 	case INTEL_FAM6_ALDERLAKE_L:
 	case INTEL_FAM6_ALDERLAKE_N:
+	case INTEL_FAM6_RAPTORLAKE:
+	case INTEL_FAM6_RAPTORLAKE_P:
+	case INTEL_FAM6_RAPTORLAKE_S:
 		adl_idle_state_table_update();
 		break;
 	}

Signature · 1 line

2.34.1

Zhang, Rui

2023-01-19 16:15 UTC #2 lore raw

In reply to Álvaro Fernández Rojas

Quoted 5 lines · Álvaro Fernández Rojas

This patch adds RaptorLake support to the intel_idle driver.
Since RaptorLake and AlderLake C-state are characteristics the same, we use
AlderLake C-states tables for RaptorLake as well.

RPL and ADL have same cstates and use the same mwait hints, but the latency of each c-state are still different on different platforms. So we can not just duplicate the ADL table on RPL.

There is an effort ongoing that measures the latency of each cstate on the RPL platforms. And based on the measurement result, we can decide if a new custom table is needed or we can just copy the previous platform. Hopefully we will have a patch in a couple of weeks.

thanks,
rui

Quoted 37 lines

Signed-off-by Álvaro Fernández Rojas <[email protected]>

---
 drivers/idle/intel_idle.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/idle/intel_idle.c +0 -0

index cfeb24d40d37..1a35b98d9bae 100644
@@ -1429,6 +1429,9 @@ static const struct x86_cpu_id intel_idle_ids[]
 __initconst = {
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE,		&idle_cpu_adl
 ),
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L,		&idle_cpu_adl
 _l),
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_N,		&idle_cpu_adl

_n),

drivers/idle/intel_idle.c +1 -0

+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE,		&idle_cpu_adl

drivers/idle/intel_idle.c +2 -0

+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_P,	&idle_cpu_adl_n),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_S,	&idle_cpu_adl),
 	X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X,	&idle_cpu_spr

drivers/idle/intel_idle.c +3 -0

 	X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL,	&idle_cpu_knl),
 	X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,	&idle_cpu_knl),

@@ -1867,6 +1870,9 @@ static void __init
 intel_idle_init_cstates_icpu(struct cpuidle_driver *drv)
 	case INTEL_FAM6_ALDERLAKE:
 	case INTEL_FAM6_ALDERLAKE_L:
 	case INTEL_FAM6_ALDERLAKE_N:
+	case INTEL_FAM6_RAPTORLAKE:
+	case INTEL_FAM6_RAPTORLAKE_P:
+	case INTEL_FAM6_RAPTORLAKE_S:
 		adl_idle_state_table_update();
 		break;

}

Guillaume Martres

2023-08-20 20:43 UTC #3 lore raw

Quoted 7 lines · Rui

Quoted 5 lines · Álvaro Fernández Rojas
This patch adds RaptorLake support to the intel_idle driver.
Since RaptorLake and AlderLake C-state are characteristics the same, we use
AlderLake C-states tables for RaptorLake as well.

Quoted 8 lines

RPL and ADL have same cstates and use the same mwait hints, but the latency of each c-state are still different on different platforms. So we can not just duplicate the ADL table on RPL.
There is an effort ongoing that measures the latency of each cstate on the RPL platforms. And based on the measurement result, we can decide if a new custom table is needed or we can just copy the previous platform. Hopefully we will have a patch in a couple of weeks.

Hi, I just stumbled upon this patch series as I was wondering about the lack of support for Raptor Lake in intel_idle. Your last message from January mentions a future patch, is it available anywhere or is this still future work?

Thank you,
Guillaume

Zhang, Rui

2023-08-20 09:21 UTC #4 lore raw

Quoted 20 lines · Guillaume Martres

Quoted 12 lines · Rui
Quoted 6 lines · Álvaro Fernández Rojas
This patch adds RaptorLake support to the intel_idle driver.
Since RaptorLake and AlderLake C-state are characteristics the same,
we use
AlderLake C-states tables for RaptorLake as well.
RPL and ADL have same cstates and use the same mwait hints, but the latency of each c-state are still different on different platforms. So we can not just duplicate the ADL table on RPL.
Quoted 6 lines
There is an effort ongoing that measures the latency of each cstate on the RPL platforms. And based on the measurement result, we
can decide if a new custom table is needed or we can just copy the previous platform. Hopefully we will have a patch in a couple of weeks.

Quoted 3 lines

Hi, I just stumbled upon this patch series as I was wondering about the
lack of support for Raptor Lake in intel_idle.

intel_idle support for RaptorLake, and also other platforms that don't have a custom table, is always there as long as we have BIOS support. The custom table is just an optimization.

Quoted 4 lines

Your last message from
January mentions a future patch, is it available anywhere or is this still future work?

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

Guillaume Martres

2023-08-20 10:32 UTC #5 lore raw

Le 20/08/2023 à 11:20, Zhang, Rui a écrit :

Quoted 21 lines · Guillaume Martres

Quoted 20 lines · Rui
Quoted 18 lines · Álvaro Fernández Rojas
Quoted 6 lines
This patch adds RaptorLake support to the intel_idle driver.
Since RaptorLake and AlderLake C-state are characteristics the same,
we use
AlderLake C-states tables for RaptorLake as well.
RPL and ADL have same cstates and use the same mwait hints, but the latency of each c-state are still different on different platforms. So we can not just duplicate the ADL table on RPL.
There is an effort ongoing that measures the latency of each cstate on the RPL platforms. And based on the measurement result, we
can decide if a new custom table is needed or we can just copy the previous platform. Hopefully we will have a patch in a couple of weeks.

Quoted 7 lines

Quoted 3 lines
Hi, I just stumbled upon this patch series as I was wondering about the
lack of support for Raptor Lake in intel_idle.
intel_idle support for RaptorLake, and also other platforms that don't have a custom table, is always there as long as we have BIOS support. The custom table is just an optimization.

Thanks for the information, I might be misinterpreting the effect of this patch then. I can report that on a Thinkpad P1 Gen 6 using a stock 6.4.11 kernel, the list of C-states looks like this:

$ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
POLL
C1_ACPI
C2_ACPI
C3_ACPI

Whereas with this patch they look like this:

$ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
POLL
C1E
C6
C8
C10

Neither of which looks quite complete (and /sys/module/intel_idle/parameters/max_cstate is set to 9). Is this something I should open a bug report about?

Thanks,
Guillaume

Zhang, Rui

2023-08-24 06:31 UTC #6 lore raw

Quoted 53 lines · Guillaume Martres

Le 20/08/2023 à 11:20, Zhang, Rui a écrit :
Quoted 33 lines · Guillaume Martres
Quoted 27 lines · Rui
Quoted 16 lines
Quoted 7 lines · Álvaro Fernández Rojas
This patch adds RaptorLake support to the intel_idle driver.
Since RaptorLake and AlderLake C-state are characteristics the
same,
we use
AlderLake C-states tables for RaptorLake as well.
RPL and ADL have same cstates and use the same mwait hints, but the
latency of each c-state are still different on different platforms.
So we can not just duplicate the ADL table on RPL.
Quoted 9 lines
There is an effort ongoing that measures the latency of each cstate on the RPL platforms. And based on the measurement result,
we
can decide if a new custom table is needed or we can just copy the
previous platform. Hopefully we will have a patch in a couple of
weeks.
Quoted 4 lines
Hi, I just stumbled upon this patch series as I was wondering about
the
lack of support for Raptor Lake in intel_idle.
Quoted 5 lines
intel_idle support for RaptorLake, and also other platforms that don't
have a custom table, is always there as long as we have BIOS support.
The custom table is just an optimization.
Thanks for the information, I might be misinterpreting the effect of this patch then. I can report that on a Thinkpad P1 Gen 6 using a stock
6.4.11 kernel, the list of C-states looks like this:
$ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
POLL
C1_ACPI
C2_ACPI
C3_ACPI

Quoted 8 lines

Whereas with this patch they look like this:
$ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
POLL
C1E
C6
C8
C10

Yeah, both of them looks reasonable.

Quoted 2 lines

Neither of which looks quite complete

Yeah, cpu can support more cstates but
ACPI can expose 3 different cstates only.
custom table can expose more, but there is no need to do so. To get
better PnP, only part of them are actually needed.

Quoted 2 lines

(and
/sys/module/intel_idle/parameters/max_cstate is set to 9).

	static int max_cstate = CPUIDLE_STATE_MAX - 1;

So 9 is the default value when the intel_idle.max_cstate parameter is not set.

Quoted 3 lines

Is this
something I should open a bug report about?

TBH, I don't see any problem here.

thanks,
rui

László Péter

2024-04-07 17:37 UTC #7 lore raw

In reply to Zhang, Rui

Quoted 12 lines · Rui

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

grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/desc /sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE /sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI FFH MWAIT 0x0 /sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI FFH MWAIT 0x21 /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH MWAIT 0x60

grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/latency /sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0 /sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state2/latency:127 /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:1048

Thanks,
Peter

Zhang, Rui

2024-04-08 02:01 UTC #8 lore raw

Quoted 16 lines · László Péter

Quoted 13 lines · Rui
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,

Quoted 8 lines

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.

Quoted 2 lines

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

Zhang, Rui

2023-01-20 04:50 UTC #9 lore raw

In reply to Álvaro Fernández Rojas

Quoted 5 lines · Álvaro Fernández Rojas

This patch adds RaptorLake support to the intel_idle driver.
Since RaptorLake and AlderLake C-state are characteristics the same, we use
AlderLake C-states tables for RaptorLake as well.

They may use the same mwait hints, but the the latency of each c-state are still different on different platforms.

Just FYI, there is an effort ongoing that measures the latency of each cstate on the RPL platforms. And based on the measurement result, we can decide if a new custom table is needed or we can just copy the previous platform.

thanks,
rui

Quoted 37 lines

Signed-off-by Álvaro Fernández Rojas <[email protected]>

---
 drivers/idle/intel_idle.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/idle/intel_idle.c +0 -0

index cfeb24d40d37..1a35b98d9bae 100644
@@ -1429,6 +1429,9 @@ static const struct x86_cpu_id intel_idle_ids[]
 __initconst = {
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE,		&idle_cpu_adl
 ),
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L,		&idle_cpu_adl
 _l),
 	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_N,		&idle_cpu_adl

_n),

drivers/idle/intel_idle.c +1 -0

+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE,		&idle_cpu_adl

drivers/idle/intel_idle.c +2 -0

+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_P,	&idle_cpu_adl_n),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_S,	&idle_cpu_adl),
 	X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X,	&idle_cpu_spr

drivers/idle/intel_idle.c +3 -0

 	X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL,	&idle_cpu_knl),
 	X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,	&idle_cpu_knl),

@@ -1867,6 +1870,9 @@ static void __init
 intel_idle_init_cstates_icpu(struct cpuidle_driver *drv)
 	case INTEL_FAM6_ALDERLAKE:
 	case INTEL_FAM6_ALDERLAKE_L:
 	case INTEL_FAM6_ALDERLAKE_N:
+	case INTEL_FAM6_RAPTORLAKE:
+	case INTEL_FAM6_RAPTORLAKE_P:
+	case INTEL_FAM6_RAPTORLAKE_S:
 		adl_idle_state_table_update();
 		break;

}