Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1526449
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID |
| Date | 2016-11-21 09:30 +0100 |
| Message-ID | <sFS9c-7d8-15@gated-at.bofh.it> (permalink) |
| References | <sEkjg-2JC-3@gated-at.bofh.it> <sEkjg-2JC-23@gated-at.bofh.it> <sEMyS-4Aj-27@gated-at.bofh.it> <sENbz-4Ni-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 18 Nov 2016, Ingo Molnar wrote:
> > * Kyle Huey <me@kylehuey.com> wrote:
> > > + if (test_tsk_thread_flag(prev_p, TIF_NOCPUID) ^
> > > + test_tsk_thread_flag(next_p, TIF_NOCPUID)) {
> > > + set_cpuid_faulting(test_tsk_thread_flag(next_p, TIF_NOCPUID));
> > > + }
> > > +
> >
> > Why not cache the required MSR value in the task struct instead?
> >
> > That would allow something much more obvious and much faster, like:
> >
> > if (prev_p->thread.misc_features_val != next_p->thread.misc_features_val)
> > wrmsrl(MSR_MISC_FEATURES_ENABLES, next_p->thread.misc_features_val);
> >
> > (The TIF flag maintenance is still required to get into __switch_to_xtra().)
> >
> > It would also be easy to extend without extra overhead, should any other feature
> > bit be added to the MSR in the future.
>
> I doubt that. There are feature enable bits coming up which are not related to
> tasks.
Any inefficiencies resulting from such features should IMHO be carried by those
features, not by per task features - but:
> [...] So if we have switches enabling/disabling global features, then we would
> be forced to chase all threads in order to update all misc_features thread
> variables. Surely not what we want to do.
What switches would those be? We generally don't twiddle global CPU features post
bootup - we pick a model on bootup and go with that.
I'd really like to see code (prototype patches are OK - or the person doing it can
send it to me privately as well if it's not production quality or public yet), or
some careful description of the features involved.
Thanks,
Ingo
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v12 0/7] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction Kyle Huey <me@kylehuey.com> - 2016-11-17 03:10 +0100
[PATCH v12 5/7] x86/cpufeature: Detect CPUID faulting support Kyle Huey <me@kylehuey.com> - 2016-11-17 03:10 +0100
Re: [PATCH v12 5/7] x86/cpufeature: Detect CPUID faulting support Borislav Petkov <bp@suse.de> - 2016-11-17 18:10 +0100
[PATCH v12 1/7] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl Kyle Huey <me@kylehuey.com> - 2016-11-17 03:10 +0100
[PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Kyle Huey <me@kylehuey.com> - 2016-11-17 03:10 +0100
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Ingo Molnar <mingo@kernel.org> - 2016-11-18 09:20 +0100
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Thomas Gleixner <tglx@linutronix.de> - 2016-11-18 10:00 +0100
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Ingo Molnar <mingo@kernel.org> - 2016-11-21 09:30 +0100
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Andy Lutomirski <luto@amacapital.net> - 2016-11-22 18:30 +0100
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Kyle Huey <me@kylehuey.com> - 2016-11-18 17:00 +0100
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Andy Lutomirski <luto@amacapital.net> - 2016-11-18 18:40 +0100
csiph-web