[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111109144440.GB8410@phenom.dumpdata.com>
Date: Wed, 9 Nov 2011 09:44:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Deepthi Dharwar <deepthi@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, len.brown@...el.com,
tglx@...utronix.de, jeremy@...p.org, hpa@...or.com, bp@...en8.de,
tj@...nel.org, trenn@...e.de, mingo@...hat.com,
xen-devel@...ts.xensource.com, stable@...nel.org
Subject: Re: [PATCH 1/3] cpuidle: If disable_cpuidle() is called, set pm_idle
to default_idle.
. 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.
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;
}
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists