lkml.org 
[lkml]   [2013]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectcpuidle sizes (Re: [PATCH 14/16] intel_idle: remove use and definition of MWAIT_MAX_NUM_CSTATES)
On 02/12/2013 05:43 PM, Daniel Lezcano wrote:
> On 02/12/2013 12:46 AM, Len Brown wrote:
>> On 02/11/2013 03:53 AM, Daniel Lezcano wrote:
>>> On 02/09/2013 02:08 AM, Len Brown wrote:
>>
>>>> The reason to change is that intel_idle will soon be able
>>>> to export more than the 8 "major" states supported by MWAIT.
>>>> When we hit that limit, it is important to know
>>>> where the limit comes from.
>>>
>>> Does it mean CPUIDLE_STATE_MAX may increase in a near future ?
>>
>> Yes, perhaps to 10.
>> Let me know if you anticipate issues with doing that.
>
> No, I don't see any issue so far. Maybe the array state is increasing
> more and more, so for most architecture it is a waste of memory, but
> anyway ...

aking a quick look at data structure sizes...

struct cpuidle_device{} is allocated per cpu --
so if we have a lot of cpus, that gets multiplied out.
But it doesn't grow much with growing CPUIDLE_STATE_MAX:

cpuidle_state_usage states_usage[CPUIDLE_STATE_MAX];
we just shrunk to 24 bytes from 32 bytes/entry.
(and 240 < 256, so we're still shrinking:-)

plus it contains cpuidle_state_kobj *kobjs[CPUIDLE_STATE_MAX];
which is a set of pointers per cpu - so with 8-byte
pointers, that would be 64->80 bytes/cpu.

The other sizes that vary with CPUIDLE_STATE_MAX
seem to be static allocations per driver --
and so they don't grow much. Did I miss something?

thanks,
Len Brown, Intel Open Source Technology Center

ps. I can easily offer an arch-specific CPUIDLE_STATE_MAX over-ride
if you want to squeeze bytes per-arch.



\
 
 \ /
  Last update: 2013-02-18 06:41    [W:0.094 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site