[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200206164614.GA20622@agluck-desk2.amr.corp.intel.com>
Date: Thu, 6 Feb 2020 08:46:14 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: Sean Christopherson <sean.j.christopherson@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Mark D Rustad <mrustad@...il.com>,
Arvind Sankar <nivedita@...m.mit.edu>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, Xiaoyao Li <xiaoyao.li@...el.com>
Subject: Re: [PATCH] x86/split_lock: Avoid runtime reads of the TEST_CTRL MSR
On Wed, Feb 05, 2020 at 05:18:23PM -0800, Andy Lutomirski wrote:
> On Wed, Feb 5, 2020 at 4:49 PM Luck, Tony <tony.luck@...el.com> wrote:
> >
> > In a context switch from a task that is detecting split locks
> > to one that is not (or vice versa) we need to update the TEST_CTRL
> > MSR. Currently this is done with the common sequence:
> > read the MSR
> > flip the bit
> > write the MSR
> > in order to avoid changing the value of any reserved bits in the MSR.
> >
> > Cache the value of the TEST_CTRL MSR when we read it during initialization
> > so we can avoid an expensive RDMSR instruction during context switch.
>
> If something else that is per-cpu-ish gets added to the MSR in the
> future, I will personally make fun of you for not making this percpu.
Xiaoyao Li has posted a version using a percpu cache value:
https://lore.kernel.org/r/20200206070412.17400-4-xiaoyao.li@intel.com
So take that if it makes you happier. My patch only used the
cached value to store the state of the reserved bits in the MSR
and assumed those are the same for all cores.
Xiaoyao Li's version updates with what was most recently written
on each thread (but doesn't, and can't, make use of that because we
know that the other thread on the core may have changed the actual
value in the MSR).
If more bits are implemented that need to be set at run time, we
are likely up the proverbial creek. I'll see if I can find out if
there are plans for that.
-Tony
Powered by blists - more mailing lists