From: Len Brown <lenb@kernel.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Len Brown <len.brown@intel.com>
Subject: cpuidle sizes (Re: [PATCH 14/16] intel_idle: remove use and definition of MWAIT_MAX_NUM_CSTATES)
Date: Mon, 18 Feb 2013 00:00:53 -0500 [thread overview]
Message-ID: <5121B585.10703@kernel.org> (raw)
In-Reply-To: <511AC5A8.4030509@linaro.org>
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.
next prev parent reply other threads:[~2013-02-18 5:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-09 1:08 idle patches queued for Linux-3.9 Len Brown
2013-02-09 1:08 ` [PATCH 01/16] intel_idle: stop using driver_data for static flags Len Brown
2013-02-09 1:08 ` [PATCH 02/16] Replace the flag by a simple global boolean in the cpuidle.c. That will allow to cleanup the rest of the code right after, because the ops won't make sense Len Brown
2013-02-09 1:08 ` [PATCH 03/16] davinci: cpuidle - move code to prevent forward declaration Len Brown
2013-02-09 1:08 ` [PATCH 04/16] davinci: cpuidle - remove the ops Len Brown
2013-02-09 1:08 ` [PATCH 05/16] davinci: cpuidle - remove useless initialization Len Brown
2013-02-09 1:08 ` [PATCH 06/16] ACPI / idle: remove unused definition Len Brown
2013-02-09 1:08 ` [PATCH 07/16] ACPI / idle : remove pointless headers Len Brown
2013-02-09 1:08 ` [PATCH 08/16] ACPI / idle: pass the cpuidle_device parameter Len Brown
2013-02-09 1:08 ` [PATCH 09/16] ACPI / idle: remove usage of the statedata Len Brown
2013-02-09 1:08 ` [PATCH 10/16] cpuidle: remove vestage definition of cpuidle_state_usage.driver_data Len Brown
2013-02-11 8:48 ` Daniel Lezcano
2013-02-09 1:08 ` [PATCH 11/16] intel_idle: support Haswell Len Brown
2013-02-09 1:08 ` [PATCH 12/16] tools/power turbostat: " Len Brown
2013-02-09 1:08 ` [PATCH 13/16] tools/power turbostat: decode MSR_IA32_POWER_CTL Len Brown
2013-02-09 1:08 ` [PATCH 14/16] intel_idle: remove use and definition of MWAIT_MAX_NUM_CSTATES Len Brown
2013-02-11 8:53 ` Daniel Lezcano
2013-02-11 23:46 ` Len Brown
2013-02-12 22:43 ` Daniel Lezcano
2013-02-18 5:00 ` Len Brown [this message]
2013-02-09 1:08 ` [PATCH 15/16] intel_idle: remove assumption of one C-state per MWAIT flag Len Brown
2013-02-09 1:08 ` [PATCH 16/16] intel_idle: export both C1 and C1E Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5121B585.10703@kernel.org \
--to=lenb@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.