[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CBF12CB.9050604@linux.intel.com>
Date: Wed, 20 Oct 2010 09:03:23 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Andi Kleen <ak@...ux.intel.com>
CC: 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 8:34 AM, Andi Kleen wrote:
>
>> but now you're duplicating this functionality adding code for everyone.
>>
>> 99.999% of the people today run cpuidle... (especially embedded x86
>> where they really care about power)
>> all x86 going forward also has > 1 idle option anyway.
>>
>> and you're adding and extra layer in the middle that just duplicates
>> the layer that's in use in practice above it.
>>
>> seriously, this sounds like the wrong tradeoff to make.
>
> I think the right option is still to put cpuidle on a diet.
> There's no reason an idle handler needs to be that bloated.
>
> If it was 2K or so just including it into the core would be fine.
>
> Ignoring code size completely is generally a wrong trade off imho.
I'm not ignoring code size.
I'm saying that a 7Kb component that everyone on this architecture uses
in practice versus adding 0.5Kb in ADDITION to that for everyone for the
theoretical case
of someone NOT using cpuidle is the wrong tradeoff.
having it go on a diet? I'm all for it. Killing off the ladder governor
for example is a step.
But really. 7Kb. There's lots of lower hanging fruit as well. 7Kb is not
a reason to make such a bad tradeoff.
--
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