[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F8FD773.5030500@linaro.org>
Date: Thu, 19 Apr 2012 11:14:27 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Peter De Schrijver <pdeschrijver@...dia.com>
CC: "Shilimkar, Santosh" <santosh.shilimkar@...com>,
Kevin Hilman <khilman@...com>, Len Brown <len.brown@...el.com>,
Trinabh Gupta <g.trinabh@...il.com>,
Russell King <linux@....linux.org.uk>,
Stephen Warren <swarren@...dotorg.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Deepthi Dharwar <deepthi@...ux.vnet.ibm.com>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
Colin Cross <ccross@...roid.com>,
Olof Johansson <olof@...om.net>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
Rob Lee <rob.lee@...aro.org>,
Ricardo Salveti <ricardo.salveti@...aro.org>
Subject: Re: [RFC PATCH] cpuidle: allow per cpu latencies
On 04/16/2012 05:34 PM, Peter De Schrijver wrote:
>>
>> Maybe we also want to make the 'disabled' flag per CPU then or provide some
>> other way the number of C states can be different per CPU?
>
> What do you think about this? Do we also want to make the disabled flag per
> CPU? Or how should we deal with a different number of C states per CPU?
Hi Peter,
yes, that could makes sense. But in most of the architecture, this is
not needed, so duplicating the state's array and latencies is unneeded
memory consumption.
Maybe we can look for a COW approach, similar to what is done for the
nsproxy structure, no ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
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/
Powered by blists - more mailing lists