linux-kernel - Re: [RFC V1] cpuidle: add idle routine registration and cleanup pm

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:	Wed, 20 Oct 2010 12:25:55 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	svaidy@...ux.vnet.ibm.com
CC:	Andi Kleen <ak@...ux.intel.com>,
	Trinabh Gupta <trinabh@...ux.vnet.ibm.com>,
	Venkatesh Pallipadi <venki@...gle.com>, peterz@...radead.org,
	lenb@...nel.org, suresh.b.siddha@...el.com,
	benh@...nel.crashing.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC V1] cpuidle: add idle routine registration and cleanup pm_idle
 pointer

  On 10/20/2010 12:19 PM, Vaidyanathan Srinivasan wrote:
> * Arjan van de Ven<arj
> I see this RFC as an incremental step to move all idle routine
> registration functionality into the kernel and keep governors and low
> level drivers as modules.  This will allow non x86 archs with just one
> idle routine to keep minimal overhead.  (Though this is becoming very
> rare).

yes pretty much all embedded really has more idle states, esp arm and co

> As stated in the goal the solution should satisfy the following
> requirements:
>
> 4. Minimal overhead for arch with following use cases
>          a) Single compile time defined idle routine, no need for
>             runtime/boot time selection

you ALWAYS have at least 2 idle handling states. The platform idle one 
and the generic busy waiting one.
the later is needed for "I want absolutely 0 latency" cases.

 > Making current cpuidle as default in kernel

not "in the kernel" but "for x86".
You're solving an x86 problem here, right?
(the pm_idle is an x86 only problem. other architectures should be able 
to keep doing what they are doing)
For x86, lets solve it by going to cpuidle period... and if Andi can 
find some bloat in cpuidle, lets see if the fat can be trimmed.

other architectures can either follow, or if they have nothing special 
and only one idle routine, can do whatever they want.

--
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/