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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Mar 2011 03:21:09 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Trinabh Gupta <trinabh@...ux.vnet.ibm.com>
Cc:	x86@...nel.org, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] [PATCH 0/9] x86 idle cruft removal - v2

> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/