Messages in this thread | | | Date | Wed, 19 Jun 2019 22:34:37 +0100 | From | Matt Fleming <> | Subject | Re: [PATCH] sched/topology: Improve load balancing on AMD EPYC |
| |
On Tue, 18 Jun, at 02:33:18PM, Peter Zijlstra wrote: > On Tue, Jun 18, 2019 at 11:43:19AM +0100, Matt Fleming wrote: > > This works for me under all my tests. Thoughts? > > > > --->8--- > > > > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > > index 80a405c2048a..4db4e9e7654b 100644 > > --- a/arch/x86/kernel/cpu/amd.c > > +++ b/arch/x86/kernel/cpu/amd.c > > @@ -8,6 +8,7 @@ > > #include <linux/sched.h> > > #include <linux/sched/clock.h> > > #include <linux/random.h> > > +#include <linux/topology.h> > > #include <asm/processor.h> > > #include <asm/apic.h> > > #include <asm/cacheinfo.h> > > @@ -824,6 +825,8 @@ static void init_amd_zn(struct cpuinfo_x86 *c) > > { > > set_cpu_cap(c, X86_FEATURE_ZEN); > > > > I'm thinking this deserves a comment. Traditionally the SLIT table held > relative memory latency. So where the identity is 10, 16 would indicate > 1.6 times local latency and 32 would be 3.2 times local. > > Now, even very early on BIOS monkeys went about their business and put > in random values in an attempt to 'tune' the system based on how > $random-os behaved, which is all sorts of fu^Wwrong. > > Now, I suppose my question is; is that 32 Zen puts in an actual relative > memory latency metric, or a random value we somehow have to deal with. > And can we pretty please describe the whole sordid story behind this > 'tunable' somewhere?
This is one for the AMD folks. I don't know if the memory latency really is 3.2 times or not, only that that's the value in all the Zen machines I have access to. Even this 2-socket one:
node distances: node 0 1 0: 10 32 1: 32 10
Tom, Suravee?
| |