From: Ricardo Neri <email@example.com> To: Thomas Gleixner <firstname.lastname@example.org> Cc: "Luck, Tony" <email@example.com>, firstname.lastname@example.org, Borislav Petkov <email@example.com>, Ingo Molnar <firstname.lastname@example.org>, Len Brown <email@example.com>, "Ravi V. Shankar" <firstname.lastname@example.org>, email@example.com, Andy Lutomirski <firstname.lastname@example.org>, "Peter Zijlstra (Intel)" <email@example.com> Subject: Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs Date: Mon, 5 Oct 2020 17:21:30 -0700 [thread overview] Message-ID: <20201006002130.GA6041@ranerica-svr.sc.intel.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Sat, Oct 03, 2020 at 12:46:29PM +0200, Thomas Gleixner wrote: > On Fri, Oct 02 2020 at 19:17, Tony Luck wrote: > > > On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote: > >> On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote: > >> > Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid > >> > part has CPUs with more than one type of micro-architecture. Thus, certain > >> > features may only be present in a specific CPU type. > >> > > >> > It is useful to know the type of CPUs present in a system. For instance, > >> > perf may need to handle CPUs differently depending on the type of micro- > >> > architecture. Decoding machine check error logs may need the additional > >> > micro-architecture type information, so include that in the log. > >> > >> 'It is useful' as justification just makes me barf. > > > > This isn't "hetero" ... all of the cores are architecturally the same. > > The above clearly says: > > >> > A hybrid part has CPUs with more than one type of micro-architecture. > > Can you folks talk to each other and chose non-ambigous wording in > changelogs and cover letters? > > > If CPUID says that some feature is supported, then it will be supported > > on all of the cores. > > That's a different story. Thank you for the quick reply, Thomas. I am sorry if my cover letter was not sufficiently clear. I see now that I should have done a more detailed discussion of the terminology. Yes, all features and instructions as enumerated in CPUID will be supported in all CPUs. Thus, the kernel will not have to check if a feature is supported before running. The hetero/hybrid part means to reflect that more than one types of CPUs will be present in the package, and the main difference is power and performance. The same kernel and user code will run on all CPUs without any other further check. > > > There might be some model specific performance counter events that only > > apply to some cores. Or a machine check error code that is logged in the > > model specific MSCOD field of IA32_MCi_STATUS. But any and all code can run > > on any core. > > Ok. The perf side should be doable, IIRC we already have something like > that, but Peter should know better. > > > Sure there will be some different power/performance tradeoffs on some > > cores. But we already have that with some cores able to achieve higher > > turbo frequencies than others. > > Right, that's not a problem. We are also working this front. Thanks and BR, Ricardo
prev parent reply other threads:[~2020-10-06 0:19 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-02 20:19 Ricardo Neri 2020-10-02 20:19 ` [PATCH 1/3] x86/cpufeatures: Enumerate hybrid CPU feature bit Ricardo Neri 2020-10-02 20:19 ` [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86 Ricardo Neri 2020-10-02 20:34 ` Borislav Petkov 2020-10-02 21:02 ` Ricardo Neri 2020-10-02 21:03 ` Borislav Petkov 2020-10-02 23:41 ` Ricardo Neri 2020-10-02 20:19 ` [PATCH 3/3] x86/mce: include type of core when reporting a machine check error Ricardo Neri 2020-10-03 1:39 ` [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs Thomas Gleixner 2020-10-03 2:17 ` Luck, Tony 2020-10-03 9:04 ` Borislav Petkov 2020-10-06 0:24 ` Ricardo Neri 2020-10-03 10:46 ` Thomas Gleixner 2020-10-03 14:39 ` Peter Zijlstra 2020-10-06 0:21 ` Ricardo Neri [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201006002130.GA6041@ranerica-svr.sc.intel.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).