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

[Duran, Leo]

Boris,

Are you saying that "amd.c' should be scheduler-aware?.. Really?

If so, are you saying that information returned by kernel-defined terms like 'Package', 'Core', etc, should done in the context of understanding the scheduler,
rather than in the context what is being documented for those terms to actually mean or represent.

I'd hope that "amd.c" should be doing the latter... and that perhaps we're simply not returning information as specified by the intended definition of those terms (in which case we need to fix our code)

Leo.

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@xxxxxxxxx]
> Sent: Tuesday, June 27, 2017 11:32 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 04:23:16PM +0000, 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 that other facilities
> can operate in generic way without having to know the processor they're
> running on.
> 
> In your particular case you're trying to address two, AFAIU, scheduling
> problems.
> 
> So no, we want to tell the scheduler *exactly* what it needs to know.
> 
> --
> Regards/Gruss,
>     Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.