| 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
| ||
|
Message-ID: <AANLkTi=Z2q7_cGkHs857bVPZK4+8U51cw7a-6A3xhO29@mail.gmail.com> Date: Wed, 20 Oct 2010 14:19:15 -0700 From: Venkatesh Pallipadi <venki@...gle.com> To: Arjan van de Ven <arjan@...ux.intel.com> Cc: svaidy@...ux.vnet.ibm.com, Andi Kleen <ak@...ux.intel.com>, Trinabh Gupta <trinabh@...ux.vnet.ibm.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 Wed, Oct 20, 2010 at 1:47 PM, Arjan van de Ven <arjan@...ux.intel.com> wrote: > On 10/20/2010 12:47 PM, Venkatesh Pallipadi wrote: >> >> On Wed, Oct 20, 2010 at 12:44 PM, Arjan van de Ven >> <arjan@...ux.intel.com> wrote: >>> >>> On 10/20/2010 12:40 PM, Vaid >>>>> >>>>> 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. >>> >>> this is not idle=poll >>> >>> this is an (privileged) app or driver, at runtime, requesting a 0 usec >>> max >>> latency for a short or long period of time. >>> >>> >>>>>> 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. >>> >>> governors as modules is a total pain. modules don't solve the problem. >>> really. it's still code you need. >>> we have two governors today, menu and ladder >>> menu is best on anything that is tickless >>> ladder is useless on any tickless kernel, and likely not better than menu >>> on >>> non-tickless. >>> that's it. >>> It will be good to have other archs also follow the same cpuidle >> >> I don't think they have to be modules. There can be a CPUIDLE_LITE >> which deCONFIG entire governor.c and individual governors (and >> probably sysfs stuff as well) for archs that can only use one state at >> any time, but still want to do config or runtime detection of one >> state and register that state. > > there is no such case though; you always have at least 2 options! > (the hardware equivalent of "hlt" and the polling option) > Agree. But, from arch perspective there is only hlt and CPUIDLE_LITE can add poll and still deconfigure all but one governor, sysfs stuff and code dealing with registering of multiple states etc for example. I am not saying doing all this is a priority. Just saying that, if ~7KB CPUIDLE is seen as a problem for some arch which does not have more than one kind of halt, then there are ways to trim CPUIDLE down. Thanks, Venki -- 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