Re: Locking issues with cpufreq and sysfs

2014-10-17 Thread Viresh Kumar
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:

Re: Locking issues with cpufreq and sysfs

2014-10-17 Thread Prarit Bhargava
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&m=140622451625236&w=2 >> >> which was introdu

Re: Locking issues with cpufreq and sysfs

2014-10-17 Thread Prarit Bhargava
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

Re: Locking issues with cpufreq and sysfs

2014-10-17 Thread Viresh Kumar
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&m=140622451625236&w=2 > > which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a

Re: Locking issues with cpufreq and sysfs

2014-10-16 Thread Viresh Kumar
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 fre

RE: Locking issues with cpufreq and sysfs

2014-10-14 Thread Elliott, Robert (Server Storage)
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 that

Re: Locking issues with cpufreq and sysfs

2014-10-14 Thread Prarit Bhargava
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

Re: Locking issues with cpufreq and sysfs

2014-10-14 Thread Viresh Kumar
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

Re: Locking issues with cpufreq and sysfs

2014-10-13 Thread Rafael J. Wysocki
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&m=140622451625236&w=2 >

Re: Locking issues with cpufreq and sysfs

2014-10-13 Thread Prarit Bhargava
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&m=140622451625236&w=2 > > which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63