On Tue, Jun 27, 2017 at 08:07:10PM +0700, Suravee Suthikulpanit wrote:
> As I have described in the cover letter, this patch series changes how
Which you didn't send to me... thanks for that.
> kernel derives cpu "package" from package-as-socket to package-as-die in
> order to fix following
On Tue, Jun 27, 2017 at 08:07:10PM +0700, Suravee Suthikulpanit wrote:
> As I have described in the cover letter, this patch series changes how
Which you didn't send to me... thanks for that.
> kernel derives cpu "package" from package-as-socket to package-as-die in
> order to fix following
+ Matt and Mel.
On Wed, Jun 28, 2017 at 03:26:10AM +0700, Suravee Suthikulpanit wrote:
> So, from the definition above, we would like all those 16 threads to be in
> the same sched-domain, where threads from C0,1,2,3 are in the same
> sched-group, and threads in C4,5,6,7 are in another
+ Matt and Mel.
On Wed, Jun 28, 2017 at 03:26:10AM +0700, Suravee Suthikulpanit wrote:
> So, from the definition above, we would like all those 16 threads to be in
> the same sched-domain, where threads from C0,1,2,3 are in the same
> sched-group, and threads in C4,5,6,7 are in another
On 6/28/17 00:44, Borislav Petkov wrote:
So let's try to discuss this without using DIE sched-domain, CCX, etc,
and let's start simple.
So in that die graphic:
C0 | T0 T1 |||| T0 T1 | C4
||||
On 6/28/17 00:44, Borislav Petkov wrote:
So let's try to discuss this without using DIE sched-domain, CCX, etc,
and let's start simple.
So in that die graphic:
C0 | T0 T1 |||| T0 T1 | C4
||||
On Tue, Jun 27, 2017 at 06:32:34PM +, Ghannam, Yazen wrote:
> > you want all those threads to belong to a single scheduling group.
> > Correct?
> >
> > Now that thing has a memory controller attached to it, correct?
> >
> > If so, why is this thing not a logical NUMA node, as described in
On Tue, Jun 27, 2017 at 06:32:34PM +, Ghannam, Yazen wrote:
> > you want all those threads to belong to a single scheduling group.
> > Correct?
> >
> > Now that thing has a memory controller attached to it, correct?
> >
> > If so, why is this thing not a logical NUMA node, as described in
kernel.org; linux-kernel@vger.kernel.org; Duran, Leo
> <leo.du...@amd.com>; Ghannam, Yazen <yazen.ghan...@amd.com>;
> Peter Zijlstra <pet...@infradead.org>
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, Jun 27, 2017 at 11:5
n, Leo
> ; Ghannam, Yazen ;
> Peter Zijlstra
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, Jun 27, 2017 at 11:54:12PM +0700, Suravee Suthikulpanit wrote:
> > The 8 threads sharing each L3 are already in the same sched-domain1
&
On Tue, Jun 27, 2017 at 11:54:12PM +0700, Suravee Suthikulpanit wrote:
> The 8 threads sharing each L3 are already in the same sched-domain1 (MC
> CCX). So, cpu0 is in the same sched-domain1 as cpu1,2,3,64,65,66,67. Here,
> we need the DIE sched-domain because it represents all cpus that are in
On Tue, Jun 27, 2017 at 11:54:12PM +0700, Suravee Suthikulpanit wrote:
> The 8 threads sharing each L3 are already in the same sched-domain1 (MC
> CCX). So, cpu0 is in the same sched-domain1 as cpu1,2,3,64,65,66,67. Here,
> we need the DIE sched-domain because it represents all cpus that are in
m>; x...@kernel.org; linux-
> ker...@vger.kernel.org; Ghannam, Yazen <yazen.ghan...@amd.com>;
> Peter Zijlstra <pet...@infradead.org>
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, Jun 27, 2017 at 04:42:32PM +, Duran, Le
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, Jun 27, 2017 at 04:42:32PM +, Duran, Leo wrote:
>
> First of all, please do not top-post.
>
> > Are you saying that "amd.c' should be scheduler-aware?.. Really?
&
Boris,
On 6/27/17 20:42, Borislav Petkov wrote:
On Tue, Jun 27, 2017 at 08:07:10PM +0700, Suravee Suthikulpanit wrote:
What we are trying point out here is that (NUMA) "node" and "die" are the
same thing in most of AMD processors, not necessary trying to introduce
another term here.
So don't
Boris,
On 6/27/17 20:42, Borislav Petkov wrote:
On Tue, Jun 27, 2017 at 08:07:10PM +0700, Suravee Suthikulpanit wrote:
What we are trying point out here is that (NUMA) "node" and "die" are the
same thing in most of AMD processors, not necessary trying to introduce
another term here.
So don't
On Tue, Jun 27, 2017 at 04:42:32PM +, Duran, Leo wrote:
First of all, please do not top-post.
> Are you saying that "amd.c' should be scheduler-aware?.. Really?
Please read again what I said.
> If so, are you saying that information returned by kernel-defined
> terms like 'Package',
On Tue, Jun 27, 2017 at 04:42:32PM +, Duran, Leo wrote:
First of all, please do not top-post.
> Are you saying that "amd.c' should be scheduler-aware?.. Really?
Please read again what I said.
> If so, are you saying that information returned by kernel-defined
> terms like 'Package',
vger.kernel.org; Ghannam, Yazen <yazen.ghan...@amd.com>;
> Peter Zijlstra <pet...@infradead.org>
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, Jun 27, 2017 at 04:23:16PM +, Duran, Leo wrote:
> > My understating is
-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, June 27, 2017 11:32 AM
> To: Duran, Leo
> Cc: 'Thomas Gleixner' ; Suthikulpanit, Suravee
> ; x...@kernel.org; linux-
> ker...@vger.kernel.org; Ghannam, Yazen ;
> Peter Zijlstra
> Subject: Re: [PATCH 1/2] x
d.com>; Borislav
> Petkov <b...@alien8.de>; x...@kernel.org; linux-kernel@vger.kernel.org;
> Ghannam, Yazen <yazen.ghan...@amd.com>; Peter Zijlstra
> <pet...@infradead.org>
> Subject: RE: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
&
kernel@vger.kernel.org;
> Ghannam, Yazen ; Peter Zijlstra
>
> Subject: RE: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, 27 Jun 2017, Duran, Leo wrote:
> > > From: Thomas Gleixner [mailto:t...@linutronix.de] On Tue, 27 Jun
> > > 2
On Tue, Jun 27, 2017 at 04:23:16PM +, Duran, Leo wrote:
> My understating is that it is *not* our job at the "amd.c" level to
> return information that influences the scheduler in any prescribed
> way.
Your understanding is wrong.
The abstractions we present to the rest of the kernel is so
On Tue, Jun 27, 2017 at 04:23:16PM +, Duran, Leo wrote:
> My understating is that it is *not* our job at the "amd.c" level to
> return information that influences the scheduler in any prescribed
> way.
Your understanding is wrong.
The abstractions we present to the rest of the kernel is so
<suravee.suthikulpa...@amd.com>; x...@kernel.org; linux-
> ker...@vger.kernel.org; Ghannam, Yazen <yazen.ghan...@amd.com>;
> Peter Zijlstra <pet...@infradead.org>
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue,
l.org; Ghannam, Yazen ;
> Peter Zijlstra
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, Jun 27, 2017 at 03:48:55PM +, Duran, Leo wrote:
> > Basically, in our case a Package may contain more than one L3 (i.e.,
> > in hardw
On Tue, 27 Jun 2017, Duran, Leo wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
> > > On 6/27/17 17:48, Borislav Petkov wrote:
> > > > On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
> > > > > However, this
On Tue, 27 Jun 2017, Duran, Leo wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
> > > On 6/27/17 17:48, Borislav Petkov wrote:
> > > > On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
> > > > > However, this
On Tue, Jun 27, 2017 at 10:55:52PM +0700, Suravee Suthikulpanit wrote:
> The reason we are trying to present "package == NUMA node (die)" here is
> because the topology.txt defines package to contain a number of cores plus
> shared resources (e.g. DRAM controller, shared caches, etc). Since the
>
On Tue, Jun 27, 2017 at 10:55:52PM +0700, Suravee Suthikulpanit wrote:
> The reason we are trying to present "package == NUMA node (die)" here is
> because the topology.txt defines package to contain a number of cores plus
> shared resources (e.g. DRAM controller, shared caches, etc). Since the
>
On Tue, Jun 27, 2017 at 03:48:55PM +, Duran, Leo wrote:
> Basically, in our case a Package may contain more than one L3 (i.e.,
> in hardware terms, there may more than one 'Core complex' in a 'Die').
> The important point is that all logical processors (threads) that
> share an L3 have a
On Tue, Jun 27, 2017 at 03:48:55PM +, Duran, Leo wrote:
> Basically, in our case a Package may contain more than one L3 (i.e.,
> in hardware terms, there may more than one 'Core complex' in a 'Die').
> The important point is that all logical processors (threads) that
> share an L3 have a
On 6/27/17 21:21, Thomas Gleixner wrote:
On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
On 6/27/17 17:48, Borislav Petkov wrote:
On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
However, this is not the case on AMD family17h multi-die processor
platforms, which can
On 6/27/17 21:21, Thomas Gleixner wrote:
On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
On 6/27/17 17:48, Borislav Petkov wrote:
On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
However, this is not the case on AMD family17h multi-die processor
platforms, which can
gt;; x...@kernel.org; linux-
> ker...@vger.kernel.org; Duran, Leo <leo.du...@amd.com>; Ghannam,
> Yazen <yazen.ghan...@amd.com>; Peter Zijlstra <pet...@infradead.org>
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue,
ran, Leo ; Ghannam,
> Yazen ; Peter Zijlstra
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
>
> On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
> > On 6/27/17 17:48, Borislav Petkov wrote:
> > > On Tue, Jun 27, 2017
Le 27/06/2017 16:21, Thomas Gleixner a écrit :
> On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
>> On 6/27/17 17:48, Borislav Petkov wrote:
>>> On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
However, this is not the case on AMD family17h multi-die processor
Le 27/06/2017 16:21, Thomas Gleixner a écrit :
> On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
>> On 6/27/17 17:48, Borislav Petkov wrote:
>>> On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
However, this is not the case on AMD family17h multi-die processor
On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
> On 6/27/17 17:48, Borislav Petkov wrote:
> > On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
> > > However, this is not the case on AMD family17h multi-die processor
> > > platforms, which can have up to 4 dies per socket
On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote:
> On 6/27/17 17:48, Borislav Petkov wrote:
> > On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
> > > However, this is not the case on AMD family17h multi-die processor
> > > platforms, which can have up to 4 dies per socket
On Tue, Jun 27, 2017 at 08:07:10PM +0700, Suravee Suthikulpanit wrote:
> What we are trying point out here is that (NUMA) "node" and "die" are the
> same thing in most of AMD processors, not necessary trying to introduce
> another term here.
So don't use it then. The whole topology topic is
On Tue, Jun 27, 2017 at 08:07:10PM +0700, Suravee Suthikulpanit wrote:
> What we are trying point out here is that (NUMA) "node" and "die" are the
> same thing in most of AMD processors, not necessary trying to introduce
> another term here.
So don't use it then. The whole topology topic is
Hi Boris,
On 6/27/17 17:48, Borislav Petkov wrote:
On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
According to the Documentation/x86/topology.txt, AMD nomenclature for
package is NUMA node (or die).
You guys keep talking about die so you should add the definition of
Hi Boris,
On 6/27/17 17:48, Borislav Petkov wrote:
On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
According to the Documentation/x86/topology.txt, AMD nomenclature for
package is NUMA node (or die).
You guys keep talking about die so you should add the definition of
Remove stable from CC - this is not how you do a stable submission.
See Documentation/process/stable-kernel-rules.rst
On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
> According to the Documentation/x86/topology.txt, AMD nomenclature for
> package is NUMA node (or die).
Remove stable from CC - this is not how you do a stable submission.
See Documentation/process/stable-kernel-rules.rst
On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote:
> According to the Documentation/x86/topology.txt, AMD nomenclature for
> package is NUMA node (or die).
According to the Documentation/x86/topology.txt, AMD nomenclature for
package is NUMA node (or die). However, this is not the case on AMD
family17h multi-die processor platforms, which can have up to 4 dies
per socket as shown in the following system topology.
Die (Dx) View :
According to the Documentation/x86/topology.txt, AMD nomenclature for
package is NUMA node (or die). However, this is not the case on AMD
family17h multi-die processor platforms, which can have up to 4 dies
per socket as shown in the following system topology.
Die (Dx) View :
48 matches
Mail list logo
