From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Kevin Hilman <khilman@ti.com>, Len Brown <len.brown@intel.com>,
Trinabh Gupta <g.trinabh@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
Stephen Warren <swarren@wwwdotorg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Deepthi Dharwar <deepthi@linux.vnet.ibm.com>,
Olof Johansson <olof@lixom.net>,
"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
Colin Cross <ccross@android.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Rob Lee <rob.lee@linaro.org>,
Arjan van de Ven <arjan@linux.intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Ricardo Salveti <ricardo.salveti@linaro.org>
Subject: Re: [RFC PATCH] cpuidle: allow per cpu latencies
Date: Thu, 19 Apr 2012 11:14:27 +0200 [thread overview]
Message-ID: <4F8FD773.5030500@linaro.org> (raw)
In-Reply-To: <20120416153456.GB514@tbergstrom-lnx.Nvidia.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] cpuidle: allow per cpu latencies
Date: Thu, 19 Apr 2012 11:14:27 +0200 [thread overview]
Message-ID: <4F8FD773.5030500@linaro.org> (raw)
In-Reply-To: <20120416153456.GB514@tbergstrom-lnx.Nvidia.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
Kevin Hilman <khilman@ti.com>, Len Brown <len.brown@intel.com>,
Trinabh Gupta <g.trinabh@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
Stephen Warren <swarren@wwwdotorg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Deepthi Dharwar <deepthi@linux.vnet.ibm.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Colin Cross <ccross@android.com>, Olof Johansson <olof@lixom.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Rob Lee <rob.lee@linaro.org>,
Ricardo Salveti <ricardo.salveti@linaro.org>
Subject: Re: [RFC PATCH] cpuidle: allow per cpu latencies
Date: Thu, 19 Apr 2012 11:14:27 +0200 [thread overview]
Message-ID: <4F8FD773.5030500@linaro.org> (raw)
In-Reply-To: <20120416153456.GB514@tbergstrom-lnx.Nvidia.com>
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
next prev parent reply other threads:[~2012-04-19 9:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-05 9:53 [RFC PATCH] cpuidle: allow per cpu latencies Peter De Schrijver
2012-04-05 9:53 ` Peter De Schrijver
2012-04-05 9:53 ` Peter De Schrijver
2012-04-05 13:37 ` Arjan van de Ven
2012-04-05 13:37 ` Arjan van de Ven
2012-04-05 13:37 ` Arjan van de Ven
[not found] ` <4F7DA009.4010802-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2012-04-06 10:32 ` Shilimkar, Santosh
2012-04-06 10:32 ` Shilimkar, Santosh
2012-04-06 10:32 ` Shilimkar, Santosh
2012-04-06 15:35 ` Daniel Lezcano
2012-04-06 15:35 ` Daniel Lezcano
[not found] ` <4F7F0D52.8080305-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-04-10 10:28 ` Peter De Schrijver
2012-04-10 10:28 ` Peter De Schrijver
2012-04-10 10:28 ` Peter De Schrijver
2012-04-16 15:34 ` Peter De Schrijver
2012-04-16 15:34 ` Peter De Schrijver
2012-04-19 9:14 ` Daniel Lezcano [this message]
2012-04-19 9:14 ` Daniel Lezcano
2012-04-19 9:14 ` Daniel Lezcano
[not found] ` <4F8FD773.5030500-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-04-19 10:23 ` Peter De Schrijver
2012-04-19 10:23 ` Peter De Schrijver
2012-04-19 10:23 ` Peter De Schrijver
2012-04-10 10:31 ` Peter De Schrijver
2012-04-10 10:31 ` Peter De Schrijver
2012-04-10 10:31 ` Peter De Schrijver
-- strict thread matches above, loose matches on Subject: below --
2012-04-05 10:44 Peter De Schrijver
2012-04-05 10:44 ` Peter De Schrijver
2012-04-05 10:44 ` Peter De Schrijver
2012-04-05 11:25 Peter De Schrijver
2012-04-05 11:25 ` Peter De Schrijver
2012-04-05 11:25 ` Peter De Schrijver
2012-04-05 12:03 ` Peter 'p2' De Schrijver
2012-04-05 12:03 ` Peter 'p2' De Schrijver
2012-04-05 12:03 ` Peter 'p2' De Schrijver
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=4F8FD773.5030500@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=arjan@linux.intel.com \
--cc=ccross@android.com \
--cc=deepthi@linux.vnet.ibm.com \
--cc=g.trinabh@gmail.com \
--cc=khilman@ti.com \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=olof@lixom.net \
--cc=pdeschrijver@nvidia.com \
--cc=ricardo.salveti@linaro.org \
--cc=rob.lee@linaro.org \
--cc=santosh.shilimkar@ti.com \
--cc=swarren@wwwdotorg.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.