linux-kernel - Re: [RFC V2 3/3] cpuidle: default idle driver for x86

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] [day] [month] [year] [list]

Date:	Thu, 13 Jan 2011 21:52:22 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Trinabh Gupta <trinabh@...ux.vnet.ibm.com>, peterz@...radead.org,
	lenb@...nel.org, suresh.b.siddha@...el.com,
	benh@...nel.crashing.org, venki@...gle.com, ak@...ux.intel.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC V2 3/3] cpuidle: default idle driver for x86

* Arjan van de Ven <arjan@...ux.intel.com> [2011-01-13 07:47:16]:

> On 1/13/2011 4:52 AM, Trinabh Gupta wrote:
> >This default cpuidle_driver parses idle= boot parameters, selects
> >the optimal idle routine for x86 during bootup and registers with
> >cpuidle. The code for idle routines and the selection of optimal
> >routine is moved from arch/x86/kernel/process.c . At module_init this
> >default driver is registered with cpuidle and for non ACPI platforms
> >it continues to be used. For ACPI platforms, acpi_idle driver would
> >replace this driver at a later point in time during bootup. Until
> >this driver's registration, architecture supplied compile time
> >default idle routine is called from within cpuidle_idle_call().
> >
> 
> 
> I like the general approach, but I'd think making idle drivers
> modular is going one step too far....
> that looks like waaay overkill to me (also since most of the actual
> idle handlers are so small
> that the overhead of the exported symbols alone is bigger than the
> idle handlers)

Agreed.  The idea of keeping them in a module is to keep the code
around for legacy systems and not have to use that code at all on
modern systems where ACPI driver can take over.

The current RFC still has not managed to pull out all the code into
the module, but suggest that it is possible.

We can keep them in-kernel and move to the next iteration where we
should ensure other architectures also can co-exist with pm_idle() and
slowly move to this approach.

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