[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8763akh4re.fsf@basil.nowhere.org>
Date: Mon, 12 Oct 2009 20:00:05 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: arun@...ux.vnet.ibm.com,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Ingo Molnar <mingo@...e.hu>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Dipankar Sarma <dipankar@...ibm.com>,
Balbir Singh <balbir@...ibm.com>,
Arjan van de Ven <arjan@...radead.org>,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-arch@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [v8 PATCH 2/8]: cpuidle: implement a list based approach to register a set of idle routines.
Peter Zijlstra <a.p.zijlstra@...llo.nl> writes:
>
> So does it make sense to have a set of sets?
>
> Why not integrate them all into one set to be ruled by this governor
> thing?
cpuidle is currently optional, that is why the two level hierarchy
is there so that you can still have simple idle selection without it.
% size drivers/cpuidle/*.o
text data bss dec hex filename
5514 1416 44 6974 1b3e drivers/cpuidle/built-in.o
Adding it unconditionally would add ~7k to everyone who wants idle functions.
I think making it unconditional would require putting it on a serious
diet first.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
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