Skip to content

Commit 08fb131

Browse files
committed
x86: set FSRS automatically on AMD CPUs that have FSRM
jira LE-1907 Rebuild_History Non-Buildable kernel-5.14.0-427.40.1.el9_4 commit-author Linus Torvalds <torvalds@linux-foundation.org> commit e046fe5 So Intel introduced the FSRS ("Fast Short REP STOS") CPU capability bit, because they seem to have done the (much simpler) REP STOS optimizations separately and later than the REP MOVS one. In contrast, when AMD introduced support for FSRM ("Fast Short REP MOVS"), in the Zen 3 core, it appears to have improved the REP STOS case at the same time, and since the FSRS bit was added by Intel later, it doesn't show up on those AMD Zen 3 cores. And now that we made use of FSRS for the "rep stos" conditional, that made those AMD machines unnecessarily slower. The Intel situation where "rep movs" is fast, but "rep stos" isn't, is just odd. The 'stos' case is a lot simpler with no aliasing, no mutual alignment issues, no complicated cases. So this just sets FSRS automatically when FSRM is available on AMD machines, to get back all the nice REP STOS goodness in Zen 3. Reported-and-tested-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit e046fe5) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
1 parent 35edb64 commit 08fb131

File tree

1 file changed

+4
-0
lines changed

1 file changed

+4
-0
lines changed

arch/x86/kernel/cpu/amd.c

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1044,6 +1044,10 @@ static void init_amd(struct cpuinfo_x86 *c)
10441044
if (c->x86 >= 0x10)
10451045
set_cpu_cap(c, X86_FEATURE_REP_GOOD);
10461046

1047+
/* AMD FSRM also implies FSRS */
1048+
if (cpu_has(c, X86_FEATURE_FSRM))
1049+
set_cpu_cap(c, X86_FEATURE_FSRS);
1050+
10471051
/* get apicid instead of initial apic id from cpuid */
10481052
c->apicid = hard_smp_processor_id();
10491053

0 commit comments

Comments
 (0)