> -----Original Message----- > From: Borislav Petkov [mailto:[email protected]] > Sent: Tuesday, June 27, 2017 11:46 AM > To: Duran, Leo <[email protected]> > Cc: 'Thomas Gleixner' <[email protected]>; Suthikulpanit, Suravee > <[email protected]>; [email protected]; linux- > [email protected]; Ghannam, Yazen <[email protected]>; > Peter Zijlstra <[email protected]> > Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of > socket > > On Tue, Jun 27, 2017 at 04:42:32PM +0000, 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', 'Core', > > "information returned by kernel-defined terms"... hmmm, I don't know what > that means. [Duran, Leo] I'm referring to: Documentation\x86\ topology.txt Started by Thomas Gleixner <[email protected]> and Borislav Petkov <[email protected]>.
> > > 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. > > -ENOPARSE. > > > 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) > > -ENOPARSE. > > I can't really understand what you're trying to tell me here. > [Duran, Leo] OK, let me try again: I'd hope that "amd.c" returns 'Package', 'Core', et al, in compliance with the document I referred to above. Allowing code that consumes the returned information to make (hopefully optimal) decisions in a vendor-agnostic way. > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
