Documentation/admin-guide/kernel-parameters.txt | 4 ++-- arch/x86/Kconfig | 2 +- arch/x86/kernel/cpu/common.c | 2 +- arch/x86/kernel/fred.c | 3 --- 4 files changed, 4 insertions(+), 7 deletions(-)
From: H. Peter Anvin (Intel) <hpa@zytor.com>
When FRED was added to the mainline kernel, it was set up as an
explicit opt-in due to the risk of regressions before hardware was
available publicly.
Now, Panther Lake (Core Ultra 300 series) has been released, and
benchmarking by Phoronix has shown that it provides a significant
performance benefit on most workloads:
https://www.phoronix.com/review/intel-fred-panther-lake
Accordingly, enable FRED by default if the CPU supports it. FRED can
of course still be disabled via the fred=off command line option.
Changes in v2:
- Ignore fred= options other than fred={on,off}. In practice
of course this means options other than fred=off.
- Remove FRED initialization message during CPU bringup (Sohil Mehta)
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/x86/Kconfig | 2 +-
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/fred.c | 3 ---
4 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a550630644..bfa8a20ccc37 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1750,8 +1750,8 @@ Kernel parameters
fred= [X86-64]
Enable/disable Flexible Return and Event Delivery.
Format: { on | off }
- on: enable FRED when it's present.
- off: disable FRED, the default setting.
+ on: enable FRED when it's present, the default setting.
+ off: disable FRED.
ftrace=[tracer]
[FTRACE] will set and start the specified tracer
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e2df1b147184..876b663dcf38 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -557,7 +557,7 @@ config X86_FRED
bool "Flexible Return and Event Delivery"
depends on X86_64
help
- When enabled, try to use Flexible Return and Event Delivery
+ When enabled, use Flexible Return and Event Delivery
instead of the legacy SYSCALL/SYSENTER/IDT architecture for
ring transitions and exception/interrupt handling if the
system supports it.
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a8ff4376c286..0b02cb038d7f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void)
/* Minimize the gap between FRED is available and available but disabled. */
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
- if (arglen != 2 || strncmp(arg, "on", 2))
+ if (arglen == 3 && !strncmp(arg, "off", 3))
setup_clear_cpu_cap(X86_FEATURE_FRED);
arglen = cmdline_find_option(boot_command_line, "clearcpuid", arg, sizeof(arg));
diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
index e736b19e18de..117aa06d25ca 100644
--- a/arch/x86/kernel/fred.c
+++ b/arch/x86/kernel/fred.c
@@ -27,9 +27,6 @@ EXPORT_PER_CPU_SYMBOL(fred_rsp0);
void cpu_init_fred_exceptions(void)
{
- /* When FRED is enabled by default, remove this log message */
- pr_info("Initialize FRED on CPU%d\n", smp_processor_id());
-
/*
* If a kernel event is delivered before a CPU goes to user level for
* the first time, its SS is NULL thus NULL is pushed into the SS fieldOn Wed, Mar 25, 2026, at 4:01 PM, H. Peter Anvin wrote: > From: H. Peter Anvin (Intel) <hpa@zytor.com> > > When FRED was added to the mainline kernel, it was set up as an > explicit opt-in due to the risk of regressions before hardware was > available publicly. > > Now, Panther Lake (Core Ultra 300 series) has been released, and > benchmarking by Phoronix has shown that it provides a significant > performance benefit on most workloads: > > https://www.phoronix.com/review/intel-fred-panther-lake Those performance increases while with fio / io_uring are ridiculous. I wonder whether anyone can looked at /proc/interrupts to try to figure out what's going on. I imagine we're bottlenecking on IO interrupts or something and FRED speeds that up by a factor of several, but this makes me wonder whether there's some tuning that should be done. Jens, for background, FRED ought to speed up page faults and interrupts (both IPI and device) by a considerable amount -- maybe a reduction of 20k or more cycles per interrupt. But Phoronix is showing up to a factor of 2 (!) actual performance increase using io_uring with a job count of 8. Now maybe 8 is too small, but I'm wondering whether the io_uring or IO part is missing some optimization that it ought to have. --Andy
On 2026-03-26 15:11, Andy Lutomirski wrote: > > Those performance increases while with fio / io_uring are ridiculous. I wonder whether anyone can looked at /proc/interrupts to try to figure out what's going on. I imagine we're bottlenecking on IO interrupts or something and FRED speeds that up by a factor of several, but this makes me wonder whether there's some tuning that should be done. > > Jens, for background, FRED ought to speed up page faults and interrupts (both IPI and device) by a considerable amount -- maybe a reduction of 20k or more cycles per interrupt. But Phoronix is showing up to a factor of 2 (!) actual performance increase using io_uring with a job count of 8. Now maybe 8 is too small, but I'm wondering whether the io_uring or IO part is missing some optimization that it ought to have. > Hi Andy! Long time no C! Either way, I presume neither of you have any problems with the patchset itself? -hpa
On 3/26/26 4:11 PM, Andy Lutomirski wrote: > > > On Wed, Mar 25, 2026, at 4:01 PM, H. Peter Anvin wrote: >> From: H. Peter Anvin (Intel) <hpa@zytor.com> >> >> When FRED was added to the mainline kernel, it was set up as an >> explicit opt-in due to the risk of regressions before hardware was >> available publicly. >> >> Now, Panther Lake (Core Ultra 300 series) has been released, and >> benchmarking by Phoronix has shown that it provides a significant >> performance benefit on most workloads: >> >> https://www.phoronix.com/review/intel-fred-panther-lake > > Those performance increases while with fio / io_uring are ridiculous. > I wonder whether anyone can looked at /proc/interrupts to try to > figure out what's going on. I imagine we're bottlenecking on IO > interrupts or something and FRED speeds that up by a factor of > several, but this makes me wonder whether there's some tuning that > should be done. I did see those results and was wondering myself what on earth is going on there. The IOPS rate isn't anywhere near high enough to saturate a single core (I saw 3-500K IOPS). I probably would've configured some polled nvme queues and ran polled IO to compare. I'm almost pondering if it's some power saving or whatever going on, and timing is enough to mess with it and change the outcome. Because outside of that, I'm a bit puzzled. I don't have a panther lake or any system that supports FRED, so all I can do is guess from here. > Jens, for background, FRED ought to speed up page faults and > interrupts (both IPI and device) by a considerable amount -- maybe a > reduction of 20k or more cycles per interrupt. But Phoronix is > showing up to a factor of 2 (!) actual performance increase using > io_uring with a job count of 8. Now maybe 8 is too small, but I'm > wondering whether the io_uring or IO part is missing some optimization > that it ought to have. He's using fio, which should do the right thing. I'm assuming job count means "8 threads doing IO", but I also don't know what the setting of each job is. Presumably each job drives a queue depth of <something> as well? With perhaps batching on the submission and completion side. Or maybe 8 jobs is a single IO thread, driving QD=8? Sorry, not much I can help with here, without having access to the system and knowing exactly what was run. And I'd also want to poke at it while it's running to get an idea of what is going on. An O_DIRECT 4k random write going from 280K to 500K IOPS is quite the change, to say the least, particularly when there's no way you're CPU bound at 280K to begin with. -- Jens Axboe
When FRED was added to the mainline kernel, it was set up as an
explicit opt-in due to the risk of regressions before hardware was
available publicly.
Now, Panther Lake (Core Ultra 300 series) has been released, and
benchmarking by Phoronix has shown that it provides a significant
performance benefit on most workloads:
https://www.phoronix.com/review/intel-fred-panther-lake
Accordingly, enable FRED by default if the CPU supports it. FRED can
of course still be disabled via the fred=off command line option.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/x86/kernel/cpu/common.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a550630644..bfa8a20ccc37 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1750,8 +1750,8 @@ Kernel parameters
fred= [X86-64]
Enable/disable Flexible Return and Event Delivery.
Format: { on | off }
- on: enable FRED when it's present.
- off: disable FRED, the default setting.
+ on: enable FRED when it's present, the default setting.
+ off: disable FRED.
ftrace=[tracer]
[FTRACE] will set and start the specified tracer
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a8ff4376c286..0b02cb038d7f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void)
/* Minimize the gap between FRED is available and available but disabled. */
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
- if (arglen != 2 || strncmp(arg, "on", 2))
+ if (arglen == 3 && !strncmp(arg, "off", 3))
setup_clear_cpu_cap(X86_FEATURE_FRED);
arglen = cmdline_find_option(boot_command_line, "clearcpuid", arg, sizeof(arg));
--
2.53.0On 3/25/2026 4:01 PM, H. Peter Anvin wrote: > Accordingly, enable FRED by default if the CPU supports it. FRED can > of course still be disabled via the fred=off command line option. > > Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> > --- Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
The following commit has been merged into the x86/fred branch of tip:
Commit-ID: ac66a73be03a0a72aeeb33d3610cfc43cb101a0b
Gitweb: https://git.kernel.org/tip/ac66a73be03a0a72aeeb33d3610cfc43cb101a0b
Author: H. Peter Anvin <hpa@zytor.com>
AuthorDate: Wed, 25 Mar 2026 16:01:47 -07:00
Committer: Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Fri, 27 Mar 2026 16:04:47 +01:00
x86/fred: Enable FRED by default
When FRED was added to the mainline kernel, it was set up as an explicit
opt-in due to the risk of regressions before hardware was available publicly.
Now, Panther Lake (Core Ultra 300 series) has been released, and benchmarking
by Phoronix has shown that it provides a significant performance benefit on
most workloads:
https://www.phoronix.com/review/intel-fred-panther-lake
Accordingly, enable FRED by default if the CPU supports it. FRED can of
course still be disabled via the fred=off command line option.
Touch up Kconfig help too.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Link: https://patch.msgid.link/20260325230151.1898287-2-hpa@zytor.com
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/x86/Kconfig | 2 +-
arch/x86/kernel/cpu/common.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a5506..bfa8a20 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1750,8 +1750,8 @@ Kernel parameters
fred= [X86-64]
Enable/disable Flexible Return and Event Delivery.
Format: { on | off }
- on: enable FRED when it's present.
- off: disable FRED, the default setting.
+ on: enable FRED when it's present, the default setting.
+ off: disable FRED.
ftrace=[tracer]
[FTRACE] will set and start the specified tracer
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e2df1b1..876b663 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -557,7 +557,7 @@ config X86_FRED
bool "Flexible Return and Event Delivery"
depends on X86_64
help
- When enabled, try to use Flexible Return and Event Delivery
+ When enabled, use Flexible Return and Event Delivery
instead of the legacy SYSCALL/SYSENTER/IDT architecture for
ring transitions and exception/interrupt handling if the
system supports it.
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a8ff437..0b02cb0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void)
/* Minimize the gap between FRED is available and available but disabled. */
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
- if (arglen != 2 || strncmp(arg, "on", 2))
+ if (arglen == 3 && !strncmp(arg, "off", 3))
setup_clear_cpu_cap(X86_FEATURE_FRED);
arglen = cmdline_find_option(boot_command_line, "clearcpuid", arg, sizeof(arg));The CONFIG_X86_FRED help text has both "try to" and "if the system
supports it", which are redundant statements.
Remove "try to".
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e2df1b147184..876b663dcf38 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -557,7 +557,7 @@ config X86_FRED
bool "Flexible Return and Event Delivery"
depends on X86_64
help
- When enabled, try to use Flexible Return and Event Delivery
+ When enabled, use Flexible Return and Event Delivery
instead of the legacy SYSCALL/SYSENTER/IDT architecture for
ring transitions and exception/interrupt handling if the
system supports it.
--
2.53.0On Wed, Mar 25, 2026 at 04:01:48PM -0700, H. Peter Anvin wrote:
> The CONFIG_X86_FRED help text has both "try to" and "if the system
> supports it", which are redundant statements.
>
> Remove "try to".
>
> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> ---
> arch/x86/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e2df1b147184..876b663dcf38 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -557,7 +557,7 @@ config X86_FRED
> bool "Flexible Return and Event Delivery"
> depends on X86_64
> help
> - When enabled, try to use Flexible Return and Event Delivery
> + When enabled, use Flexible Return and Event Delivery
> instead of the legacy SYSCALL/SYSENTER/IDT architecture for
> ring transitions and exception/interrupt handling if the
> system supports it.
> --
I'll merge this one with patch 1 - it is too minute and belongs there too
anyway.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
From: Sohil Mehta <sohil.mehta@intel.com>
When FRED is enabled, its initialization message is printed for every
CPU during boot as well as during suspend-resume. This debug message can
be noisy and it isn't very useful unless someone is debugging FRED
itself.
As FRED is enabled by default, remove the log message as mentioned in
the code comment.
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
arch/x86/kernel/fred.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
index e736b19e18de..117aa06d25ca 100644
--- a/arch/x86/kernel/fred.c
+++ b/arch/x86/kernel/fred.c
@@ -27,9 +27,6 @@ EXPORT_PER_CPU_SYMBOL(fred_rsp0);
void cpu_init_fred_exceptions(void)
{
- /* When FRED is enabled by default, remove this log message */
- pr_info("Initialize FRED on CPU%d\n", smp_processor_id());
-
/*
* If a kernel event is delivered before a CPU goes to user level for
* the first time, its SS is NULL thus NULL is pushed into the SS field
--
2.53.0The following commit has been merged into the x86/fred branch of tip:
Commit-ID: f0958d588e6de263224ca92087b45ce72fa25c91
Gitweb: https://git.kernel.org/tip/f0958d588e6de263224ca92087b45ce72fa25c91
Author: Sohil Mehta <sohil.mehta@intel.com>
AuthorDate: Wed, 25 Mar 2026 16:01:49 -07:00
Committer: Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Fri, 27 Mar 2026 16:38:24 +01:00
x86/fred: Remove kernel log message when initializing exceptions
When FRED is enabled, its initialization message is printed for every CPU
during boot as well as during suspend-resume. This debug message can be noisy
and it isn't very useful unless someone is debugging FRED itself.
As FRED is enabled by default, remove the log message as mentioned in
the code comment.
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260325230151.1898287-4-hpa@zytor.com
---
arch/x86/kernel/fred.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
index e736b19..117aa06 100644
--- a/arch/x86/kernel/fred.c
+++ b/arch/x86/kernel/fred.c
@@ -27,9 +27,6 @@ EXPORT_PER_CPU_SYMBOL(fred_rsp0);
void cpu_init_fred_exceptions(void)
{
- /* When FRED is enabled by default, remove this log message */
- pr_info("Initialize FRED on CPU%d\n", smp_processor_id());
-
/*
* If a kernel event is delivered before a CPU goes to user level for
* the first time, its SS is NULL thus NULL is pushed into the SS field© 2016 - 2026 Red Hat, Inc.