lkml.org 
[lkml]   [2005]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Lse-tech] Re: [PATCH] cpusets+hotplug+preepmt broken
On Fri, May 13, 2005 at 12:59:53PM -0700, Paul Jackson wrote:
> Srivatsa, replying to Dinakar:
> > This in fact was the reason that we added lock_cpu_hotplug
> > in sched_setaffinity.
>
> We do need to be clear about how these locks work, their semantics, what
> they require and what they insure, and their various interactions.
>
> This is not easy stuff to get right.
>
> I notice that the documentation for lock_cpu_hotplug() is a tad on
> the skimpy side:
>
> /* Stop CPUs going up and down. */
>
> That's it, so far as I can see. Interaction of hotplug locking with
> the rest of the kernel has been, is now, and will continue to be, a
> difficult area. More care than this needs to be put into explaining
> the use, semantics and interactions of any locking involved.
>
> In particular, in my view, locks should guard data. What data does
> lock_cpu_hotplug() guard? I propose that it guards cpu_online_map.
>
> I recommend considering a different name for this lock. Perhaps
> 'cpu_online_sem', instead of 'cpucontrol'? And perhaps the
> lock_cpu_hotplug() should be renamed, to say 'lock_cpu_online'?

No. CPU hotplug uses two different locking - see both lock_cpu_hotplug()
and __stop_machine_run(). Anyone reading cpu_online_map with
preemption disabled is safe from cpu hotplug even without taking
any lock.

Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-13 22:51    [W:0.074 / U:2.056 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site