x86/amd: disable way access filter on affected CPUs
PATCH 1/1 x86/amd: disable way access filter on affected CPUs
The WAF may hurt the performance of some workloads, caused by aliasing issues in the L1 cache.
Disable it on the affected CPUs.
--- arch/x86/kernel/cpu/amd.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
arch/x86/kernel/cpu/amd.c +14 -0
@@ -631,6 +631,20 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } } +/* +* The way access filter has a performance penalty on some workloads. +* Disable it on the affected CPUs. +*/ +if ((c->x86 ==0x15 ) && + (c->x86_model >=0x02 ) && (c->x86_model <0x20 )) { +u64 val; + +if (!rdmsrl_safe (0xc0011021 , &val) && !(val &0x1E )) { + val |=0x1E ; +wrmsrl_safe (0xc0011021 , val); + } + } +cpu_detect_cache_sizes (c);/* Multi core CPU? */
Signature · 1 line
1.7.12.1
Quoted 20 lines · Andre Przywara
The WAF may hurt the performance of some workloads, caused by aliasing issues in the L1 cache.
Disable it on the affected CPUs.Signed-off-by Andre Przywara <[email protected]>--- arch/x86/kernel/cpu/amd.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)arch/x86/kernel/cpu/amd.c +3
-0@@ -631,6 +631,20 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } } +/* +* The way access filter has a performance penalty on some workloads. +* Disable it on the affected CPUs.
arch/x86/kernel/cpu/amd.c static void __cpuinit init_amd(struct cpuinfo_x86 *c) · line 646
Quoted 10 lines
arch/x86/kernel/cpu/amd.c +10
-0+*/ +if ((c->x86 ==0x15 ) && + (c->x86_model >=0x02 ) && (c->x86_model <0x20 )) { +u64 val; + +if (!rdmsrl_safe (0xc0011021 , &val) && !(val &0x1E )) { + val |=0x1E ; +wrmsrl_safe (0xc0011021 , val); + } + }
Would be nice to hear more about the background of this change, about the amount of 'penalty' and the nature of the workloads. Also, it would be useful to know how the [0x02..0x1f] model range was chosen.
Thanks,
Ingo
Quoted 20 lines · Ingo Molnar
Quoted 17 lines · Andre Przywara
The WAF may hurt the performance of some workloads, caused by aliasing issues in the L1 cache.
Disable it on the affected CPUs.Signed-off-by Andre Przywara <[email protected]>--- arch/x86/kernel/cpu/amd.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)arch/x86/kernel/cpu/amd.c +0
-0@@ -631,6 +631,20 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } }
Quoted 16 lines
arch/x86/kernel/cpu/amd.c static void __cpuinit init_amd(struct cpuinfo_x86 *c) · line 646
Quoted 13 lines
arch/x86/kernel/cpu/amd.c +13
-0+/* +* The way access filter has a performance penalty on some workloads. +* Disable it on the affected CPUs. +*/ +if ((c->x86 ==0x15 ) && + (c->x86_model >=0x02 ) && (c->x86_model <0x20 )) { +u64 val; + +if (!rdmsrl_safe (0xc0011021 , &val) && !(val &0x1E )) { + val |=0x1E ; +wrmsrl_safe (0xc0011021 , val); + } + }Would be nice to hear more about the background of this change, about the amount of 'penalty' and the nature of the workloads.
The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
That new patch does not replace the old one, we just need another quirk for newer CPUs.
The penalty depends on the circumstances, if you need a number, I can only tell you the 3% from last year.
The workloads would be those that access code from the same physical page under different virtual addresses, so different processes using the same libraries with ASLR or multiple instances of PIE-binaries. The code needs to be accessed simultaneously from both cores of the same compute unit.
More details here:
http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf
Quoted 2 lines
Also, it would be useful to know how the [0x02..0x1f] model range was chosen.
That is everything that has the core known as Piledriver.
That includes the AMD A-Series (aka Trinity) and the just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2, A-Series has model 10h, with possible extensions to 1Fh. Hence the range of model ids. Model 2 CPUs should have the fix in BIOS, but I guess there are quite some boxes out there which will not be updated. Better safe than sorry.
Regards,
Andre.
Signature · 3 lines
Andre Przywara AMD-OSRC (Dresden) Tel: x29712
Quoted 58 lines · Andre Przywara
Quoted 20 lines · Ingo Molnar
Quoted 17 lines · Andre Przywara
The WAF may hurt the performance of some workloads, caused by aliasing issues in the L1 cache.
Disable it on the affected CPUs.Signed-off-by Andre Przywara <[email protected]>--- arch/x86/kernel/cpu/amd.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)arch/x86/kernel/cpu/amd.c +0
-0@@ -631,6 +631,20 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } }Quoted 16 lines
arch/x86/kernel/cpu/amd.c static void __cpuinit init_amd(struct cpuinfo_x86 *c) · line 646
Quoted 13 lines
arch/x86/kernel/cpu/amd.c +13
-0+/* +* The way access filter has a performance penalty on some workloads. +* Disable it on the affected CPUs. +*/ +if ((c->x86 ==0x15 ) && + (c->x86_model >=0x02 ) && (c->x86_model <0x20 )) { +u64 val; + +if (!rdmsrl_safe (0xc0011021 , &val) && !(val &0x1E )) { + val |=0x1E ; +wrmsrl_safe (0xc0011021 , val); + } + }Would be nice to hear more about the background of this change, about the amount of 'penalty' and the nature of the workloads.
The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
That new patch does not replace the old one, we just need another quirk for newer CPUs.The penalty depends on the circumstances, if you need a number, I can only tell you the 3% from last year.
The workloads would be those that access code from the same physical page under different virtual addresses, so different processes using the same libraries with ASLR or multiple instances of PIE-binaries. The code needs to be accessed simultaneously from both cores of the same compute unit.
More details here:
http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdfQuoted 2 lines
Also, it would be useful to know how the [0x02..0x1f] model range was chosen.
Quoted 9 lines
That is everything that has the core known as Piledriver. That includes the AMD A-Series (aka Trinity) and the just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2, A-Series has model 10h, with possible extensions to 1Fh. Hence the range of model ids.
Model 2 CPUs should have the fix in BIOS, but I guess there are quite some boxes out there which will not be updated. Better safe than sorry.
Most of this info makes a perfect changelog entry - mind sending an updated v2 patch with this information included?
Thanks,
Ingo
PATCH 1/1 x86/amd: disable way access filter on affected CPUs
From: Andre Przywara <[email protected]>
The Way Access Filter in recent AMD CPUs may hurt the performance of some workloads, caused by aliasing issues in the L1 cache. This patch disables it on the affected CPUs.
The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
This new patch does not replace the old one, we just need another quirk for newer CPUs.
The performance penalty without the patch depends on the circumstances, but is a bit less than the last year's 3%.
The workloads affected would be those that access code from the same physical page under different virtual addresses, so different processes using the same libraries with ASLR or multiple instances of PIE-binaries. The code needs to be accessed simultaneously from both cores of the same compute unit.
More details can be found here:
http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf
CPUs affected are anything with the core known as Piledriver. That includes the new parts of the AMD A-Series (aka Trinity) and the just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2, A-Series has model 10h, with possible extensions to 1Fh. Hence the range of model ids.
--- arch/x86/kernel/cpu/amd.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)
arch/x86/kernel/cpu/amd.c +14 -0
@@ -631,6 +631,20 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } } +/* +* The way access filter has a performance penalty on some workloads. +* Disable it on the affected CPUs. +*/ +if ((c->x86 ==0x15 ) && + (c->x86_model >=0x02 ) && (c->x86_model <0x20 )) { +u64 val; + +if (!rdmsrl_safe (0xc0011021 , &val) && !(val &0x1E )) { + val |=0x1E ; +wrmsrl_safe (0xc0011021 , val); + } + } +cpu_detect_cache_sizes (c);/* Multi core CPU? */
Signature · 1 line
1.7.1
[tip:x86/urgent] x86, amd: Disable way access filter on Piledriver CPUs
Commit-ID: 2bbf0a1427c377350f001fbc6260995334739ad7 Gitweb: http://git.kernel.org/tip/2bbf0a1427c377350f001fbc6260995334739ad7 Author: Andre Przywara <[email protected]> AuthorDate: Wed, 31 Oct 2012 17:20:50 +0100 Committer: H. Peter Anvin <[email protected]> CommitDate: Wed, 31 Oct 2012 13:06:55 -0700
x86, amd: Disable way access filter on Piledriver CPUs
The Way Access Filter in recent AMD CPUs may hurt the performance of some workloads, caused by aliasing issues in the L1 cache. This patch disables it on the affected CPUs.
The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
This new patch does not replace the old one, we just need another quirk for newer CPUs.
The performance penalty without the patch depends on the circumstances, but is a bit less than the last year's 3%.
The workloads affected would be those that access code from the same physical page under different virtual addresses, so different processes using the same libraries with ASLR or multiple instances of PIE-binaries. The code needs to be accessed simultaneously from both cores of the same compute unit.
More details can be found here:
http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf
CPUs affected are anything with the core known as Piledriver. That includes the new parts of the AMD A-Series (aka Trinity) and the just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2, A-Series has model 10h, with possible extensions to 1Fh. Hence the range of model ids.
--- arch/x86/kernel/cpu/amd.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)
arch/x86/kernel/cpu/amd.c +14 -0
@@ -631,6 +631,20 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } } +/* +* The way access filter has a performance penalty on some workloads. +* Disable it on the affected CPUs. +*/ +if ((c->x86 ==0x15 ) && + (c->x86_model >=0x02 ) && (c->x86_model <0x20 )) { +u64 val; + +if (!rdmsrl_safe (0xc0011021 , &val) && !(val &0x1E )) { + val |=0x1E ; +wrmsrl_safe (0xc0011021 , val); + } + } +cpu_detect_cache_sizes (c);/* Multi core CPU? */