[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161121082721.GA22520@gmail.com>
Date: Mon, 21 Nov 2016 09:27:21 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Kyle Huey <me@...ehuey.com>,
Robert O'Callahan <robert@...llahan.org>,
Andy Lutomirski <luto@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Jeff Dike <jdike@...toit.com>,
Richard Weinberger <richard@....at>,
Alexander Viro <viro@...iv.linux.org.uk>,
Shuah Khan <shuah@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Borislav Petkov <bp@...e.de>,
Peter Zijlstra <peterz@...radead.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Len Brown <len.brown@...el.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Dmitry Safonov <dsafonov@...tuozzo.com>,
David Matlack <dmatlack@...gle.com>,
Nadav Amit <nadav.amit@...il.com>,
linux-kernel@...r.kernel.org,
user-mode-linux-devel@...ts.sourceforge.net,
user-mode-linux-user@...ts.sourceforge.net,
linux-fsdevel@...r.kernel.org, linux-kselftest@...r.kernel.org,
kvm@...r.kernel.org
Subject: Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
* Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, 18 Nov 2016, Ingo Molnar wrote:
> > * Kyle Huey <me@...ehuey.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
Powered by blists - more mailing lists