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]

Message-ID: <20101020194045.GB706@dirshya.in.ibm.com>
Date:	Thu, 21 Oct 2010 01:10:45 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Arjan van de Ven <arjan@...ux.intel.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

* Arjan van de Ven <arjan@...ux.intel.com> [2010-10-20 12:25:55]:

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

Some special overrides like idle=poll should handle this case even if
cpuidle and related registration mechanism is compiled out. The point
is that we need some flexibility even if the full framework is not
included.

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

Ok, you are suggesting that for x86 lets move cpuidle in kernel
always, while it can be an optional module for other archs as it
stands today.  We can slim down the cpuidle from current 7K or atleast
split some parts like governors as modules if needed.

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

It will be good to have other archs also follow the same cpuidle
framework and call it from their kernel/idle routines so that we need
not have a hierarchy of idle routines there.

--Vaidy

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