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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
