On 17 October 2014 17:45, Prarit Bhargava wrote:
> Hmmm
>
> This is what I'm doing:
>
> echo ondemand > scaling_governor
> cat ondemand/*
> echo conservative > scaling_governor
>
> OOC what are you doing to test?
Exactly same and even tried Roberts script too :)
--
To unsubscribe from this list:
On 10/17/2014 07:38 AM, Viresh Kumar wrote:
> On 13 October 2014 18:41, Prarit Bhargava wrote:
>> There are several issues with the current locking design of cpufreq. Most
>> notably is the panic reported here:
>>
>> http://marc.info/?l=linux-kernel=140622451625236=2
>>
>> which was introduced
On 10/16/2014 07:23 AM, Viresh Kumar wrote:
> On 14 October 2014 23:54, Prarit Bhargava wrote:
>> Here's what I think we should do. Taking a step back, the purpose of the
>> cpufreq sysfs files is to allow userspace to read current cpu frequency
>> settings, and to allow userspce to modify the
On 13 October 2014 18:41, Prarit Bhargava wrote:
> There are several issues with the current locking design of cpufreq. Most
> notably is the panic reported here:
>
> http://marc.info/?l=linux-kernel=140622451625236=2
>
> which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a,
>
On 13 October 2014 18:41, Prarit Bhargava pra...@redhat.com wrote:
There are several issues with the current locking design of cpufreq. Most
notably is the panic reported here:
http://marc.info/?l=linux-kernelm=140622451625236w=2
which was introduced by commit
On 10/16/2014 07:23 AM, Viresh Kumar wrote:
On 14 October 2014 23:54, Prarit Bhargava pra...@redhat.com wrote:
Here's what I think we should do. Taking a step back, the purpose of the
cpufreq sysfs files is to allow userspace to read current cpu frequency
settings, and to allow userspce to
On 10/17/2014 07:38 AM, Viresh Kumar wrote:
On 13 October 2014 18:41, Prarit Bhargava pra...@redhat.com wrote:
There are several issues with the current locking design of cpufreq. Most
notably is the panic reported here:
http://marc.info/?l=linux-kernelm=140622451625236w=2
which was
On 17 October 2014 17:45, Prarit Bhargava pra...@redhat.com wrote:
Hmmm
This is what I'm doing:
echo ondemand scaling_governor
cat ondemand/*
echo conservative scaling_governor
OOC what are you doing to test?
Exactly same and even tried Roberts script too :)
--
To unsubscribe from this
On 14 October 2014 23:54, Prarit Bhargava wrote:
> Here's what I think we should do. Taking a step back, the purpose of the
> cpufreq sysfs files is to allow userspace to read current cpu frequency
> settings, and to allow userspce to modify the governor and set the max & min
> ranges for cpu
On 14 October 2014 23:54, Prarit Bhargava pra...@redhat.com wrote:
Here's what I think we should do. Taking a step back, the purpose of the
cpufreq sysfs files is to allow userspace to read current cpu frequency
settings, and to allow userspce to modify the governor and set the max min
rg; Linux
> Kernel; Robert Schöne
> Subject: Re: Locking issues with cpufreq and sysfs
>
> On 10/14/2014 03:10 AM, Viresh Kumar wrote:
> > On 13 October 2014 18:41, Prarit Bhargava wrote:
> >>
> >> The locking is insufficient here, Viresh. I no longer believe th
On 10/14/2014 03:10 AM, Viresh Kumar wrote:
> On 13 October 2014 18:41, Prarit Bhargava wrote:
>>
>> The locking is insufficient here, Viresh. I no longer believe that fixes
>> to this locking scheme are the right way to move forward here. I'm wondering
>> if we can look at other alternatives
On 13 October 2014 18:41, Prarit Bhargava wrote:
> There are several issues with the current locking design of cpufreq. Most
Sadly yes :(
> [Question: was the original reported deadlock "real"? Did it really happen or
> did lockdep only report it (I may have asked this question previously and
On 13 October 2014 18:41, Prarit Bhargava pra...@redhat.com wrote:
There are several issues with the current locking design of cpufreq. Most
Sadly yes :(
[Question: was the original reported deadlock real? Did it really happen or
did lockdep only report it (I may have asked this question
On 10/14/2014 03:10 AM, Viresh Kumar wrote:
On 13 October 2014 18:41, Prarit Bhargava pra...@redhat.com wrote:
The locking is insufficient here, Viresh. I no longer believe that fixes
to this locking scheme are the right way to move forward here. I'm wondering
if we can look at other
Schöne
Subject: Re: Locking issues with cpufreq and sysfs
On 10/14/2014 03:10 AM, Viresh Kumar wrote:
On 13 October 2014 18:41, Prarit Bhargava pra...@redhat.com wrote:
The locking is insufficient here, Viresh. I no longer believe that fixes
to this locking scheme are the right way to move
On Monday, October 13, 2014 09:22:49 AM Prarit Bhargava wrote:
>
> On 10/13/2014 09:11 AM, Prarit Bhargava wrote:
> > There are several issues with the current locking design of cpufreq. Most
> > notably is the panic reported here:
> >
> > http://marc.info/?l=linux-kernel=140622451625236=2
> >
On 10/13/2014 09:11 AM, Prarit Bhargava wrote:
> There are several issues with the current locking design of cpufreq. Most
> notably is the panic reported here:
>
> http://marc.info/?l=linux-kernel=140622451625236=2
>
> which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a,
There are several issues with the current locking design of cpufreq. Most
notably is the panic reported here:
http://marc.info/?l=linux-kernel=140622451625236=2
which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a,
cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT,
There are several issues with the current locking design of cpufreq. Most
notably is the panic reported here:
http://marc.info/?l=linux-kernelm=140622451625236w=2
which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a,
cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT,
On 10/13/2014 09:11 AM, Prarit Bhargava wrote:
There are several issues with the current locking design of cpufreq. Most
notably is the panic reported here:
http://marc.info/?l=linux-kernelm=140622451625236w=2
which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a,
On Monday, October 13, 2014 09:22:49 AM Prarit Bhargava wrote:
On 10/13/2014 09:11 AM, Prarit Bhargava wrote:
There are several issues with the current locking design of cpufreq. Most
notably is the panic reported here:
http://marc.info/?l=linux-kernelm=140622451625236w=2
which
22 matches
Mail list logo
