RE: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of socket

[Duran, Leo]

Boris,
Please see my comments below.
Leo.

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@xxxxxxxxx]
> Sent: Tuesday, June 27, 2017 11:12 AM
> To: Duran, Leo <leo.duran@xxxxxxx>
> Cc: 'Thomas Gleixner' <tglx@xxxxxxxxxxxxx>; Suthikulpanit, Suravee
> <Suravee.Suthikulpanit@xxxxxxx>; x86@xxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; Ghannam, Yazen <Yazen.Ghannam@xxxxxxx>;
> Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of
> socket
> 
> On Tue, Jun 27, 2017 at 03:48:55PM +0000, 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 common "cpu_llc_id".
> 
> All that means nothing if it doesn't have any effect on scheduling.
> 
> If moving the working set between L3s within the package, as you call it, is
> not measureable, i.e., task migration, then we don't care. The whole exercise
> is not about modelling the hardware topology accurately but for presenting
> sufficient detailed topology to the scheduler so that it works optimally on
> Zen.
[Duran, Leo] 
My understanding is the intent of the vendor-specific CPU topology code (in our case, amd.c) is to accurately present topology to the kernel, based on the 'abstractions' the kernel has defined.
(abstractions being terms like "Package", "cpu_llc_id", etc)

It is then up-to code that consumes the kernel-defined abstraction to ensure optimal use of the returned topology information.

That is,
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.
If that were the case, it would seem to me that the code consuming the returned topology information is 'broken', or that the defined abstractions are 'broken'.


> 
> --
> Regards/Gruss,
>     Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.