el.org; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency
>
>Hi Venki,
>On Wed, Dec 06, 2006 at 10:27:01AM -0800, Pallipadi, Venkatesh wrote:
>
>> But, if we make cpufreq more
Hi Venki,
On Wed, Dec 06, 2006 at 10:27:01AM -0800, Pallipadi, Venkatesh wrote:
> But, if we make cpufreq more affected_cpus aware and have a per_cpu
> target()
> call by moving set_cpus_allowed() from driver into cpufreq core and
> define
> the target function to be atomic/non-sleeping type, then
t;[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency
>
>On Thu, Nov 30, 2006 at 12:03:15PM +0100, Ingo Molnar wrote:
>>
>> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>>
>> &g
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> Consider a case where we have three locks A, B and C.
> We have very clear locking rule inside the kernel that lock A *should*
> be acquired before acquiring either lock B or lock C.
>
> At runtime lockdep detects the two dependency chains,
> A -->
On Thu, Nov 30, 2006 at 09:29:34AM +0100, Ingo Molnar wrote:
> what lockdep does is it observes actual locking dependencies as they
> happen individually in various contexts, and then 'completes' the
> dependency graph by combining all the possible scenarios how contexts
> might preempt each other.
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Even with complex inter-subsystem interactions, hotplugging could be
> > effectively and scalably controlled via a self-recursive per-CPU
> > mutex, and a pointer to it embedded in task_struct:
> So what I would propose is that rather than going a
On Thu, 30 Nov 2006 12:46:17 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > This would be done totally serialized and while holding the hotplug
> > > lock, so no CPU could go away or arrive while this operation is
> > > going on.
> >
> > You s
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> In process context preemptible code,
> Lets say we are currently running on processor i.
>
> cpu_hotplug_lock() ; /* does mutex_lock(&percpu(hotplug_lock, i)) */
>
> /* do some operation, which might sleep */
> /* migrates to cpu j */
>
> cpu_ho
On Thu, Nov 30, 2006 at 12:46:17PM +0100, Ingo Molnar wrote:
>
> struct task_struct {
> ...
> int hotplug_depth;
> struct mutex *hotplug_lock;
> }
> ...
>
> DEFINE_PER_CPU(struct mutex, hotplug_lock);
>
> void cpu_hotplug_lo
On Thu, Nov 30, 2006 at 12:53:27PM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > This is what is currently being done by cpufreq:
>
> ok!
>
> > a) get_some_cpu_hotplug_protection() [use either some global mechanism
> > or a
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> This is what is currently being done by cpufreq:
ok!
> a) get_some_cpu_hotplug_protection() [use either some global mechanism
> or a persubsystem mutex]
this bit is wrong i think. Any reason why it's not a p
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > This would be done totally serialized and while holding the hotplug
> > lock, so no CPU could go away or arrive while this operation is
> > going on.
>
> You said "the hotplug lock". That is the problem.
maybe i'm too dense today but i still don
On Thu, Nov 30, 2006 at 12:03:15PM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > a) cpufreq maintain's it's own cpumask in the variable
> > policy->affected_cpus and says : If a frequency change is issued to
> > any one of the cpu's in the affected_cpus mask, y
On Thu, 30 Nov 2006 12:03:15 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > a) cpufreq maintain's it's own cpumask in the variable
> > policy->affected_cpus and says : If a frequency change is issued to
> > any one of the cpu's in the affec
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> a) cpufreq maintain's it's own cpumask in the variable
> policy->affected_cpus and says : If a frequency change is issued to
> any one of the cpu's in the affected_cpus mask, you change frequency
> on all cpus in the mask. So this needs to be con
On Thu, Nov 30, 2006 at 09:31:44AM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > So do we
> > - Rethink the strategy of per-subsystem hotcpu-locks ?
> >
> > OR
> >
> > - Think of a way to straighten out the super-convoluted cpufreq code ?
>
> i'm still wonde
On Thu, Nov 30, 2006 at 09:29:34AM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > Ok, I see that we are already doing it :(. So we can end up in a
> > deadlock.
> >
> > Here's the culprit callpath:
>
> in general lockdep is 100% correct when it comes to "indivi
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> So do we
> - Rethink the strategy of per-subsystem hotcpu-locks ?
>
> OR
>
> - Think of a way to straighten out the super-convoluted cpufreq code ?
i'm still wondering what the conceptual source of this fundamental
locking complexity in cpuf
* Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> Ok, I see that we are already doing it :(. So we can end up in a
> deadlock.
>
> Here's the culprit callpath:
in general lockdep is 100% correct when it comes to "individual locks".
The overwhelming majority of lockdep false-positives is not due
On Thu, Nov 30, 2006 at 09:58:07AM +0530, Gautham R Shenoy wrote:
>
> So can we ignore this circular-dep warning as a false positive?
> Or is there a way to exploit this circular dependency ?
>
> At the moment, I cannot think of way to exploit this circular dependency
> unless we do something lik
On Wed, Nov 29, 2006 at 01:05:56PM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 20:54:04 +0530
> Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
>
> > Ok, so to cut the long story short,
> > - While changing governor from anything to
> > ondemand, locks are taken in the following order
> >
> > po
On Wed, 29 Nov 2006 20:54:04 +0530
Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> Ok, so to cut the long story short,
> - While changing governor from anything to
> ondemand, locks are taken in the following order
>
> policy->lock ===> dbs_mutex ===> workqueue_mutex.
>
> - While offlining a cpu,
Hi all,
Looks like the lockdep has resumed yelling about the cpufreq-cpu hotplug
interactions! Again, it's the Ondemand governor that's the culprit.
On linux-2.6.19-rc6-mm2, this is what I got yesterday evening.
[EMAIL PROTECTED] tests]# echo ondemand >
/sys/devices/system/cpu/cpu0/cpufreq/sca
23 matches
Mail list logo
