Re: [linux-pm] [PATCH 0/9] x86 idle cruft removal - v2

[Len Brown]

> > What is next:
> > 
> > handle c1e_idle() vs default_idle()
> > 	run-time check for AMD workaround enable as part of default_idle?
> > give xen_arch_setup default_idle() w/o having it touch pm_idle
> > 	perhaps it can simply set a flag to disable cpuidle...
> > 		which is what would run if the xen kernel were
> > 		booted on raw iron.  Or can we handle this
> > 		at compile time?
> 
> I guess it may be good to have a method to override cpuidle and
> force it to call default_idle from inside cpuidle_idle_call(). This
> could be useful for users other than xen in future. Ofcourse this override
> should not touch pm_idle (which would be removed anyway).

Actually what I was thinking was the ability to disable cpuidle
altogether via cmdline.  ie a run-time equivalent of CONFIG_CPU_IDLE=n.
eg. "cpuidle=0"  In that case cpu_idle_call() would return error
and we'd have:

cpu_idle()
	if (cpu_idle_call())
		default_idle()

This is also a clean way for CONFIG_CPU_IDLE=n to work.

> Provision is already there to call default_idle from inside
> cpuidle_idle_call(); we can use that after checking a flag?? Can
> we use something like boot_option_idle_override? Or set/unset
> flag through an API?

I think it is strange for cpuidle to turn around and
call back to default_idle().  I'd like to see if we can
keep knowledge of default_idle() inside process.c.
If cpuidle can't do better than default_idle()
then it sholdn't be running...

> > delete pm_idle
> > 	x86 will then use default_idle or cpuidle
> > allow cpuidle to use default_idle to handle the period
> > 	where it polls because cpus have not yet registered
> 
> If we remove pm_idle and directly call cpuidle, the
> check already exists to call default_idle until a cpuidle
> driver (and cpus) is registered.

it isn't working.
If it were, then we'd not see any polling in the cpuidle stats.

cheers,
-Len

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/