Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-02 Thread Viresh Kumar
On 02-06-15, 12:26, Preeti U Murthy wrote: > dbs_data->mutex_lock is used to serialize only START,STOP,LIMIT calls. > It does not serialize EXIT/INIT with these operations, but that is Yeah, we need to fix that. To be honest, locking is in real bad shape in cpufreq core and its required to get it

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Preeti U Murthy
On 06/02/2015 11:57 AM, Viresh Kumar wrote: > On 02-06-15, 11:50, Preeti U Murthy wrote: >> CPU0CPU1 >> >> store* store* >> >> lock(policy 1) lock(policy 2) >> cpufreq_set_policy() cpufreq_set_policy() >> EXIT() : >> dbs-data->usage_co

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Viresh Kumar
On 02-06-15, 11:50, Preeti U Murthy wrote: > CPU0CPU1 > > store* store* > > lock(policy 1) lock(policy 2) > cpufreq_set_policy() cpufreq_set_policy() > EXIT() : > dbs-data->usage_count-- > > INIT() EXIT() When

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Preeti U Murthy
On 06/02/2015 11:41 AM, Viresh Kumar wrote: > On 02-06-15, 11:33, Preeti U Murthy wrote: >> No, dbs_data is a governor wide data structure and not a policy wide > > Yeah, that's the common part which I was referring to. But normally > its just read for policies in START/STOP, they just update per-

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Viresh Kumar
On 02-06-15, 11:33, Preeti U Murthy wrote: > No, dbs_data is a governor wide data structure and not a policy wide Yeah, that's the common part which I was referring to. But normally its just read for policies in START/STOP, they just update per-cpu data for policy->cpus. > one, which is manipulat

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Preeti U Murthy
On 06/02/2015 11:09 AM, Viresh Kumar wrote: > On 02-06-15, 11:01, Preeti U Murthy wrote: >> How will a policy lock help here at all, when cpus from multiple >> policies are calling into __cpufreq_governor() ? How will a policy lock >> serialize their entry into cpufreq_governor_dbs() ? > > So diff

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Viresh Kumar
On 02-06-15, 11:01, Preeti U Murthy wrote: > How will a policy lock help here at all, when cpus from multiple > policies are calling into __cpufreq_governor() ? How will a policy lock > serialize their entry into cpufreq_governor_dbs() ? So different policies don't really depend on each other. The

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Preeti U Murthy
On 06/01/2015 12:49 PM, Viresh Kumar wrote: > On 01-06-15, 01:40, Preeti U Murthy wrote: > > I have to mention that this is somewhat inspired by: > > https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5 > > and I was waiting to finish some core-cha

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Preeti U Murthy
On 06/01/2015 12:49 PM, Viresh Kumar wrote: > On 01-06-15, 01:40, Preeti U Murthy wrote: > > I have to mention that this is somewhat inspired by: > > https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5 > > and I was waiting to finish some core-cha

Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions

2015-06-01 Thread Viresh Kumar
On 01-06-15, 01:40, Preeti U Murthy wrote: I have to mention that this is somewhat inspired by: https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5 and I was waiting to finish some core-changes to make all this simple. I am fine to you trying to