[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 07/11] x86/intel_pstate: changes in cpufreq_del_cpu for CPU offline



On 23/06/2015 16:08, Jan Beulich wrote:
> >>> On 23.06.15 at 08:16, <wei.w.wang@xxxxxxxxx> wrote:
> > On 19/06/2015 17:44, Jan Beulich wrote:
> >> >>> On 11.06.15 at 10:28, <wei.w.wang@xxxxxxxxx> wrote:
> >> > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we
> >> > change to NULL it after the call of cpufreq_driver->exit.
> >> > Otherwise, a calltrace will show up on your screen due to the
> >> > reference of a NULL pointer when you power down the system.
> >>
> >> Apart from what was already said on this patch, I think it is placed
> >> too late in this series (should precede patch 6) or, even better, not
> >> needed at all: ->exit() gets passed the policy being cleaned up, so I
> >> don't follow why the driver needs to consult the per-CPU field to obtain 
> >> it.
> >
> >> Plus, if the patch is to be kept, the description suggesting this to
> >> be a problem at system shutdown only is wrong - it can equally well
> >> happen while offlining a CPU. Just saying that the pointer is still needed
> would be sufficient.
> >
> > It's needed. When unplugging a CPU, the intel_pstate driver sets it to
> > run with the lowest P-state.
> 
> I understand the latter, but this doesn't explain why you can't do what I
> suggested above.

Because the "->exit()" needs to call "intel_pstate_set_pstate()" which does not 
receive "policy" as a parameter. "intel_pstate_set_pstate()" is also called by 
another function without passing "policy". So I think it is simpler to just 
change the order of NULLing the pointer, instead of changing more code.

Best,
Wei  

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.