linux-kernel - cpuidle sizes (Re: [PATCH 14/16] intel_idle: remove use and definition of MWAIT_MAX_NUM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5121B585.10703@kernel.org>
Date:	Mon, 18 Feb 2013 00:00:53 -0500
From:	Len Brown <lenb@...nel.org>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>
CC:	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Len Brown <len.brown@...el.com>
Subject: cpuidle 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.

--
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/