lkml.org 
[lkml]   [2015]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] intel_pstate: set BYT MSR with wrmsrl_on_cpu()
On Fri, 08 May 2015 15:59:14 +0200
"Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:

> On Thursday, May 07, 2015 04:22:32 PM Joe Konno wrote:
> > On Thu, May 07, 2015 at 10:58:11PM +0200, Rafael J. Wysocki wrote:
> > > On Thursday, May 07, 2015 09:59:39 AM Joe Konno wrote:
> > > > From: Joe Konno <joe.konno@intel.com>
> > > >
> > > > In instances where the default cpufreq governor is Performance, reading
> > >
> > > I'm not really sure what this is about. You're talking about cpufreq governors
> > > and this is an intel_pstate patch. What gives?
> >
> > I'll reshuffle the paragraph to bring detail to the fix first, and the
> > "when/why" second.
> >
> > In debug I have only seen the bug during boot when cpufreq calls
> > intel_pstate's init for each logical core-- often from one, sometimes
> > two logical cores.
> >
> > The bug may occur after init as well, but not enough data to conclude
> > one way or the other. I personally have not seen it happen after init in
> > my local testing.
> >
> > >
> > > > from MSR 0x199 on an applicable multi-core Atom system saw boot-to-boot
> > > > variability in the P-State value set to each logical core. Sometimes
> > > > only one logical core would be set properly, other times two or three.
> > > > There was an assumption in the code that only a thread on the intended
> > > > logical core would be calling the wrmsrl() function. That was disproven
> > > > during debug, as cpufreq, at init, was not always calling from the same
> > > > as the logical core it targeted. Thus, use wrmsrl_on_cpu() instead, as
> > > > done in the core_set_pstate() function.
> > > >
> > > > For: LCK-1822
> > >
> > > This tag is meaningless upstream.
> >
> > Mimicked another subsystem's practice. I have no problem removing it.
> >
> > >
> > > > Fixes: 007bea098b86 ("intel_pstate: Add setting voltage value for
> > > > baytrail P states.")
> > >
> > > So, you're fixing a function introduced by the above commit, right?
> >
> > Correct. That commit introduced the byt_set_pstate() function with the
> > wrmsrl() call.
> >
> > >
> > > > Signed-off-by: Joe Konno <joe.konno@intel.com>
> > > > ---
> > > > drivers/cpufreq/intel_pstate.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > > > index 6414661ac1c4..c45d274a75c8 100644
> > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > @@ -535,7 +535,7 @@ static void byt_set_pstate(struct cpudata *cpudata, int pstate)
> > > >
> > > > val |= vid;
> > > >
> > > > - wrmsrl(MSR_IA32_PERF_CTL, val);
> > > > + wrmsrl_on_cpu(cpudata->cpu, MSR_IA32_PERF_CTL, val);
> > >
> > > So the bug is that this may run on a CPU which is not cpudata->cpu in which
> > > case the write will not happen where it should. Is that correct?
> >
> > Yes-- I believe my first inline comment spoke to this.
>
> So here's the changelog I'd use with this patch:
>
> "Commit 007bea098b86 (intel_pstate: Add setting voltage value for baytrail
> P states.) introduced byt_set_pstate() with the assumption that it would
> always be run by the CPU whose MSR is to be written by it. It turns out,
> however, that is not always the case in practice, so modify byt_set_pstate()
> to enforce the MSR write done by it to always happen on the right CPU."
>
> I don't think you need to say anything more in it. Mentioning governors in
> particular is unnecessary and confusing.
>
> Kristen, what do you think?
>
>

Looks good to me with the modified changelog.

Acked-by: Kristen Carlson Accardi <kristen@linux.intel.com>


\
 
 \ /
  Last update: 2015-05-11 21:21    [W:0.697 / U:2.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site