Hi Sherry,
On Tue, Mar 22, 2016 at 03:10:15AM -0500, Sherry Hurwitz wrote:
> Boris, this documentation will help tremendously.
Yeah, I'm collecting more stuff for it. If you feel like something else
should be explained there, holler.
> In just this line of
> code:
>
> nr_local_cpus = nr_cores *
On 03/21/2016 08:57 AM, Borislav Petkov wrote:
+- AMD: the number of cores in a processor. On a system where cores are
+clustered in groups of 2, 4 or more in compute units, this variable
+denotes the number of*compute units* on the node.
+
+In both cases, the number of scheduling threads is com
On Fri, Mar 18, 2016 at 11:03:47PM +0800, Peter Zijlstra wrote:
> It turns out AMD gets x86_max_cores wrong when there are compute
> units.
>
> The issue is that Linux assumes:
>
> nr_logical_cpus = nr_cores * nr_siblings
>
> But AMD reports its CU unit as 2 cores, but then sets num_smp_si
On Mon, Mar 21, 2016 at 05:46:12PM +0800, Huang Rui wrote:
> OK, maybe, we would better add a comment to explain here. :-)
Here's a start:
---
From: Borislav Petkov
Date: Mon, 21 Mar 2016 14:53:05 +0100
Subject: [PATCH] x86/Documentation: Start documenting x86 topology
This should contain impor
On Mon, Mar 21, 2016 at 06:05:16PM +0800, Huang Rui wrote:
> Looks better. I will test it on fam16h machine tomorrow, if it's OK,
> will add my Test-by.
Sure.
Thanks!
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
On Mon, Mar 21, 2016 at 09:23:41AM +0100, Borislav Petkov wrote:
> On Mon, Mar 21, 2016 at 11:07:46AM +0800, Huang Rui wrote:
> > OK, we will find some fam15h, fam16h platforms to verify it. Please
> > wait for my feedback.
> >
> > But I am confused with c->x86_max_cores /= smp_num_siblings, what
On Mon, Mar 21, 2016 at 09:21:29AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 11:07:46AM +0800, Huang Rui wrote:
> > > > The issue is that Linux assumes:
> > > >
> > > > nr_logical_cpus = nr_cores * nr_siblings
> > > >
> > > > But AMD reports its CU unit as 2 cores, but then s
On Mon, Mar 21, 2016 at 09:26:43AM +0100, Borislav Petkov wrote:
> On Mon, Mar 21, 2016 at 11:46:19AM +0800, Huang Rui wrote:
> > I quickly applied this patch on tip/master with on a fam15h machine.
> > The issue is still existed, only one core can be detected.
>
> Huh, what?
>
> So that 6386 has
On Mon, 21 Mar 2016, Huang Rui wrote:
> I quickly applied this patch on tip/master with on a fam15h machine.
Can you use tip/x86/urgent please?
Thanks,
tglx
On Mon, Mar 21, 2016 at 11:46:19AM +0800, Huang Rui wrote:
> I quickly applied this patch on tip/master with on a fam15h machine.
> The issue is still existed, only one core can be detected.
Huh, what?
So that 6386 has 16 cores, according to wikipedia, that must be 8
compute units. Correct?
Are
On Mon, Mar 21, 2016 at 11:07:46AM +0800, Huang Rui wrote:
> OK, we will find some fam15h, fam16h platforms to verify it. Please
> wait for my feedback.
>
> But I am confused with c->x86_max_cores /= smp_num_siblings, what is
> the real meaning of c->x86_max_cores here for AMD, the whole compute
>
On Mon, Mar 21, 2016 at 11:07:46AM +0800, Huang Rui wrote:
> > > The issue is that Linux assumes:
> > >
> > > nr_logical_cpus = nr_cores * nr_siblings
> > >
> > > But AMD reports its CU unit as 2 cores, but then sets num_smp_siblings
> > > to 2 as well.
> But I am confused with c->x86_max_core
On Mon, Mar 21, 2016 at 11:07:44AM +0800, Huang Rui wrote:
> On Fri, Mar 18, 2016 at 05:41:01PM +0100, Borislav Petkov wrote:
> > On Fri, Mar 18, 2016 at 04:03:47PM +0100, Peter Zijlstra wrote:
> > > It turns out AMD gets x86_max_cores wrong when there are compute
> > > units.
> > >
> > > The issu
On Fri, Mar 18, 2016 at 05:41:01PM +0100, Borislav Petkov wrote:
> On Fri, Mar 18, 2016 at 04:03:47PM +0100, Peter Zijlstra wrote:
> > It turns out AMD gets x86_max_cores wrong when there are compute
> > units.
> >
> > The issue is that Linux assumes:
> >
> > nr_logical_cpus = nr_cores * nr_s
On Sun, Mar 20, 2016 at 06:08:47PM +0100, Peter Zijlstra wrote:
> On Sun, Mar 20, 2016 at 02:09:26PM +0100, Borislav Petkov wrote:
> > First a question about the big picture: why is amd/core.c even
> > dealing with NB counters?
>
> It it not, it is dealing with Fam10 NB events.
>
> Fam10h doesn't
On Sun, Mar 20, 2016 at 02:09:26PM +0100, Borislav Petkov wrote:
> First a question about the big picture: why is amd/core.c even
> dealing with NB counters?
It it not, it is dealing with Fam10 NB events.
Fam10h doesn't have NB counters. Its NB events are on the same counters
as all the other eve
On Sun, Mar 20, 2016 at 01:46:29PM +0100, Peter Zijlstra wrote:
> On Sun, Mar 20, 2016 at 01:32:25PM +0100, Peter Zijlstra wrote:
> > Yes, but IIRC the F15h driver doesn't use the NB constraints, as they
> > moved all the NB events to their own set of MSRs, which has
> > events/amd/uncore.c.
> >
>
On Sun, Mar 20, 2016 at 01:32:25PM +0100, Peter Zijlstra wrote:
> Yes, but IIRC the F15h driver doesn't use the NB constraints, as they
> moved all the NB events to their own set of MSRs, which has
> events/amd/uncore.c.
>
> So all the NB cruft in the core pmu is only relevant to F10h.
>
> So F15
On Sun, Mar 20, 2016 at 12:04:55PM +0100, Borislav Petkov wrote:
> On Sun, Mar 20, 2016 at 11:39:46AM +0100, Peter Zijlstra wrote:
> > So the AMD NB stuff in events/amd/core.c is only for Fam10, Fam15 got
> > its own uncore driver. (Fam10 had the uncore events through the same
> > counters as the c
On Fri, Mar 18, 2016 at 04:03:47PM +0100, Peter Zijlstra wrote:
> It turns out AMD gets x86_max_cores wrong when there are compute
> units.
>
> The issue is that Linux assumes:
>
> nr_logical_cpus = nr_cores * nr_siblings
>
> But AMD reports its CU unit as 2 cores, but then sets num_smp_si
On Sun, Mar 20, 2016 at 11:39:46AM +0100, Peter Zijlstra wrote:
> So the AMD NB stuff in events/amd/core.c is only for Fam10, Fam15 got
> its own uncore driver. (Fam10 had the uncore events through the same
> counters as the core PMU with with 'fun' constraints).
>
> And since Fam10 isn't affected
On Sat, Mar 19, 2016 at 10:24:59AM +0100, Thomas Gleixner wrote:
> Unfortunately that will break stuff in event/amd/core.c, ras/mce_amd_inj.c
> which rely on the AMD interpretation of c->x86_max_cores.
So the AMD NB stuff in events/amd/core.c is only for Fam10, Fam15 got
its own uncore driver. (Fa
On Sat, Mar 19, 2016 at 10:24:59AM +0100, Thomas Gleixner wrote:
> On Fri, 18 Mar 2016, Peter Zijlstra wrote:
> > It turns out AMD gets x86_max_cores wrong when there are compute
> > units.
> >
> > The issue is that Linux assumes:
> >
> > nr_logical_cpus = nr_cores * nr_siblings
> >
> > But
On Fri, 18 Mar 2016, Peter Zijlstra wrote:
> It turns out AMD gets x86_max_cores wrong when there are compute
> units.
>
> The issue is that Linux assumes:
>
> nr_logical_cpus = nr_cores * nr_siblings
>
> But AMD reports its CU unit as 2 cores, but then sets num_smp_siblings
> to 2 as well
It turns out AMD gets x86_max_cores wrong when there are compute
units.
The issue is that Linux assumes:
nr_logical_cpus = nr_cores * nr_siblings
But AMD reports its CU unit as 2 cores, but then sets num_smp_siblings
to 2 as well.
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Thomas Gleixne
25 matches
Mail list logo
