cpuidle sizes (Re: [PATCH 14/16] intel_idle: remove use and definitionof MWAIT_MAX_NUM_CSTATES)

[Len Brown]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/