On 07/16/2014 11:14 AM, Viresh Kumar wrote:
> On 15 July 2014 12:28, Srivatsa S. Bhat wrote:
>> Wait, allowing an offline CPU to be the policy->cpu (i.e., the CPU which is
>> considered as the master of the policy/group) is just absurd.
>
> Yeah, that was as Absurd as I am :)
>
I have had my
On 07/15/2014 11:05 PM, skan...@codeaurora.org wrote:
>
> Srivatsa S. Bhat wrote:
>> On 07/15/2014 11:06 AM, Saravana Kannan wrote:
>>> On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan wrote:
> Yeah, it definitely crashes if policy->cpu if an offline
On 07/15/2014 11:05 PM, skan...@codeaurora.org wrote:
Srivatsa S. Bhat wrote:
On 07/15/2014 11:06 AM, Saravana Kannan wrote:
On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote:
Yeah, it definitely crashes if policy-cpu if an
On 07/16/2014 11:14 AM, Viresh Kumar wrote:
On 15 July 2014 12:28, Srivatsa S. Bhat sriva...@mit.edu wrote:
Wait, allowing an offline CPU to be the policy-cpu (i.e., the CPU which is
considered as the master of the policy/group) is just absurd.
Yeah, that was as Absurd as I am :)
I have
On 15 July 2014 12:28, Srivatsa S. Bhat wrote:
> Wait, allowing an offline CPU to be the policy->cpu (i.e., the CPU which is
> considered as the master of the policy/group) is just absurd.
Yeah, that was as Absurd as I am :)
> The goal of this patchset should be to just de-couple the sysfs
>
Srivatsa S. Bhat wrote:
> On 07/15/2014 11:06 AM, Saravana Kannan wrote:
>> On 07/14/2014 09:35 PM, Viresh Kumar wrote:
>>> On 15 July 2014 00:38, Saravana Kannan wrote:
Yeah, it definitely crashes if policy->cpu if an offline cpu. Because
the
mutex would be uninitialized if it's
On 07/15/2014 11:06 AM, Saravana Kannan wrote:
> On 07/14/2014 09:35 PM, Viresh Kumar wrote:
>> On 15 July 2014 00:38, Saravana Kannan wrote:
>>> Yeah, it definitely crashes if policy->cpu if an offline cpu. Because
>>> the
>>> mutex would be uninitialized if it's stopped after boot or it would
On 07/15/2014 11:06 AM, Saravana Kannan wrote:
On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote:
Yeah, it definitely crashes if policy-cpu if an offline cpu. Because
the
mutex would be uninitialized if it's stopped after boot or
Srivatsa S. Bhat wrote:
On 07/15/2014 11:06 AM, Saravana Kannan wrote:
On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote:
Yeah, it definitely crashes if policy-cpu if an offline cpu. Because
the
mutex would be uninitialized if
On 15 July 2014 12:28, Srivatsa S. Bhat sriva...@mit.edu wrote:
Wait, allowing an offline CPU to be the policy-cpu (i.e., the CPU which is
considered as the master of the policy/group) is just absurd.
Yeah, that was as Absurd as I am :)
The goal of this patchset should be to just de-couple
On 15 July 2014 11:06, Saravana Kannan wrote:
> Btw, I tried to take a stab at removing any assumption in cpufreq code about
> policy->cpu being ONLINE. There are 160 instances of those of with 23 are in
> cpufreq.c
>
> So, even if we are sure cpufreq.c is fine, it's 137 other uses spread across
On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan wrote:
Yeah, it definitely crashes if policy->cpu if an offline cpu. Because the
mutex would be uninitialized if it's stopped after boot or it would never
have been initialized (depending on how you fix
On 15 July 2014 00:38, Saravana Kannan wrote:
> Yeah, it definitely crashes if policy->cpu if an offline cpu. Because the
> mutex would be uninitialized if it's stopped after boot or it would never
> have been initialized (depending on how you fix policy->cpu at boot).
>
> Look at this snippet on
On 07/13/2014 11:13 PM, Viresh Kumar wrote:
On 12 July 2014 08:36, Saravana Kannan wrote:
On 07/10/2014 11:19 PM, Viresh Kumar wrote:
Please make sure you take care of these issues:
- suspend/resume
- hotplug
- module insert/remove
Ok, I was just at the current code. Does
On 07/13/2014 11:09 PM, Viresh Kumar wrote:
On 12 July 2014 08:14, Saravana Kannan wrote:
I'm just always adding the real nodes to the first CPU in a cluster
independent of which CPU gets added first. Makes it easier to know which
ones to symlink. See comment next to policy->cpu for full
On 12 July 2014 08:36, Saravana Kannan wrote:
> On 07/10/2014 11:19 PM, Viresh Kumar wrote:
>
>>
>> Please make sure you take care of these issues:
>> - suspend/resume
>> - hotplug
>> - module insert/remove
>
> Ok, I was just at the current code. Does cpufreq_unregister_driver() even
> really
On 12 July 2014 08:14, Saravana Kannan wrote:
>>> I'm just always adding the real nodes to the first CPU in a cluster
>>> independent of which CPU gets added first. Makes it easier to know which
>>> ones to symlink. See comment next to policy->cpu for full context.
>>
>>
>> Yeah, and that is the
On 12 July 2014 08:14, Saravana Kannan skan...@codeaurora.org wrote:
I'm just always adding the real nodes to the first CPU in a cluster
independent of which CPU gets added first. Makes it easier to know which
ones to symlink. See comment next to policy-cpu for full context.
Yeah, and that
On 12 July 2014 08:36, Saravana Kannan skan...@codeaurora.org wrote:
On 07/10/2014 11:19 PM, Viresh Kumar wrote:
Please make sure you take care of these issues:
- suspend/resume
- hotplug
- module insert/remove
Ok, I was just at the current code. Does cpufreq_unregister_driver() even
On 07/13/2014 11:09 PM, Viresh Kumar wrote:
On 12 July 2014 08:14, Saravana Kannan skan...@codeaurora.org wrote:
I'm just always adding the real nodes to the first CPU in a cluster
independent of which CPU gets added first. Makes it easier to know which
ones to symlink. See comment next to
On 07/13/2014 11:13 PM, Viresh Kumar wrote:
On 12 July 2014 08:36, Saravana Kannan skan...@codeaurora.org wrote:
On 07/10/2014 11:19 PM, Viresh Kumar wrote:
Please make sure you take care of these issues:
- suspend/resume
- hotplug
- module insert/remove
Ok, I was just at the current code.
On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote:
Yeah, it definitely crashes if policy-cpu if an offline cpu. Because the
mutex would be uninitialized if it's stopped after boot or it would never
have been initialized (depending on how you fix policy-cpu at boot).
Look at
On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote:
Yeah, it definitely crashes if policy-cpu if an offline cpu. Because the
mutex would be uninitialized if it's stopped after boot or it would never
have been initialized (depending on
On 15 July 2014 11:06, Saravana Kannan skan...@codeaurora.org wrote:
Btw, I tried to take a stab at removing any assumption in cpufreq code about
policy-cpu being ONLINE. There are 160 instances of those of with 23 are in
cpufreq.c
So, even if we are sure cpufreq.c is fine, it's 137 other
On 07/10/2014 11:19 PM, Viresh Kumar wrote:
Please make sure you take care of these issues:
- suspend/resume
- hotplug
- module insert/remove
Ok, I was just at the current code. Does cpufreq_unregister_driver()
even really work correctly as it stands?
It doesn't even seem to stop any of the
On 07/11/2014 03:52 AM, Viresh Kumar wrote:
Just responding to one comment. The one about policy->cpu.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
static int cpufreq_add_dev_symlink(struct cpufreq_policy *policy)
{
- unsigned int j;
+ unsigned int j,
On 11 July 2014 15:29, wrote:
> Viresh Kumar wrote:
>> On 11 July 2014 09:48, Saravana Kannan wrote:
>>> * Policy settings and governor tunables maintained across suspend/resume
>>> and hotplug.
>>
>> Its already maintained during suspend/resume.
>
> But not across hotplug. Which is also
skan...@codeaurora.org wrote:
>
> Viresh Kumar wrote:
>> Hi Saravana,
>>
>> Thanks for trying this..
>>
>> On 11 July 2014 09:48, Saravana Kannan wrote:
>>> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
>>
>> s/driver/core
>
> Will do
>
S many typos. This is what
Srivatsa S. Bhat wrote:
> On 07/11/2014 09:48 AM, Saravana Kannan wrote:
>> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
>> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
>> moving policy ownership between CPUs, it also moves the cpufreq sysfs
Viresh Kumar wrote:
> Hi Saravana,
>
> Thanks for trying this..
>
> On 11 July 2014 09:48, Saravana Kannan wrote:
>> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
>
> s/driver/core
Will do
>
>> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
On 07/11/2014 09:48 AM, Saravana Kannan wrote:
> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
> moving policy ownership between CPUs, it also moves the cpufreq sysfs
> directory between CPUs and
Hi Saravana,
Thanks for trying this..
On 11 July 2014 09:48, Saravana Kannan wrote:
> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
s/driver/core
> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
> moving policy ownership between CPUs, it
Hi Saravana,
Thanks for trying this..
On 11 July 2014 09:48, Saravana Kannan skan...@codeaurora.org wrote:
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
s/driver/core
CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
moving policy ownership
On 07/11/2014 09:48 AM, Saravana Kannan wrote:
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
moving policy ownership between CPUs, it also moves the cpufreq sysfs
directory between CPUs and also
Viresh Kumar wrote:
Hi Saravana,
Thanks for trying this..
On 11 July 2014 09:48, Saravana Kannan skan...@codeaurora.org wrote:
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
s/driver/core
Will do
CPUs within a cluster (CPUs sharing same policy) go
Srivatsa S. Bhat wrote:
On 07/11/2014 09:48 AM, Saravana Kannan wrote:
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
moving policy ownership between CPUs, it also moves the cpufreq sysfs
skan...@codeaurora.org wrote:
Viresh Kumar wrote:
Hi Saravana,
Thanks for trying this..
On 11 July 2014 09:48, Saravana Kannan skan...@codeaurora.org wrote:
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
s/driver/core
Will do
snip
S many typos. This is
On 11 July 2014 15:29, skan...@codeaurora.org wrote:
Viresh Kumar wrote:
On 11 July 2014 09:48, Saravana Kannan skan...@codeaurora.org wrote:
* Policy settings and governor tunables maintained across suspend/resume
and hotplug.
Its already maintained during suspend/resume.
But not
On 07/11/2014 03:52 AM, Viresh Kumar wrote:
Just responding to one comment. The one about policy-cpu.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
static int cpufreq_add_dev_symlink(struct cpufreq_policy *policy)
{
- unsigned int j;
+ unsigned int j,
On 07/10/2014 11:19 PM, Viresh Kumar wrote:
Please make sure you take care of these issues:
- suspend/resume
- hotplug
- module insert/remove
Ok, I was just at the current code. Does cpufreq_unregister_driver()
even really work correctly as it stands?
It doesn't even seem to stop any of the
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
moving policy ownership between CPUs, it also moves the cpufreq sysfs
directory between CPUs and also fixes up the symlinks of the other CPUs in
the
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
moving policy ownership between CPUs, it also moves the cpufreq sysfs
directory between CPUs and also fixes up the symlinks of the other CPUs in
the
42 matches
Mail list logo
