[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH 1/3] cpuidle: If disable_cpuidle() is called, set pm_idle to default_idle.
On Wednesday 09 November 2011 08:14 PM, Konrad Rzeszutek Wilk wrote: > . snip.. >>> >>> ..scribble on pm_idle and access default_idle, >>> have it simply disable_cpuidle() so acpi_idle will not load and >>> architecture default HLT will be used. >>> >>> .. but the default HLT does not get used. Instead we end up in the > > Hey Deepthi, > >>> + if (cpuidle_disabled()) { >>> + pm_idle = default_idle; >>> + return; >>> + } >> >> >> The above check is needed to initialise pm_idle to default_idle if >> cpuidle is disabled but this requirement here is Zen specific. >> On other architectures, if cpuidle is disabled on boot then we >> rather would want mwait_idle or amd_e400_idle to be enabled than >> default_idle. Can we make this check Zen specific ? > > We do? Why? I would have thought that if you want to disable the cpuidle > you would want the default_idle. Well I was with a view that if cpuidle is disabled, mwait and arm_e400 would take precedence over default_idle. But if is ok to have default_idle instead, then go ahead. > Perhaps there is another way do this is: > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c > index becd6d9..04b10a4 100644 > --- a/drivers/cpuidle/cpuidle.c > +++ b/drivers/cpuidle/cpuidle.c > @@ -38,6 +38,7 @@ int cpuidle_disabled(void) > void disable_cpuidle(void) > { > off = 1; > + pm_idle = default_idle; > } > Brining pm_idle pointer back to cpuidle code is going a step back coz we wanted to complete remove using pm_idle going forward. As having a pointer exported into various files is not a good thing. That's the reason we started the clean up in the first place :) > which would do almost the same thing as this patch (well, except > that if you run cpuidle.off=1 you still end up with amd_e400_idle > instead of default_idle, so it is not the complete solution). > >> >> ... if(ZEN_ARCH && cpuidle_disabled()) ... > > That would not work very well. For one thing you would need to call > 'xen_domain()', and pull in a lots of header files. Second of, it > looks quite ugly and kernel folks like pretty code. > Yes, I agree to this. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |