Re: [patch] Reorganize the cpufreq cpu hotplug locking to not be totally bizare

From: Ashok Raj
Date: Thu Jul 27 2006 - 13:46:01 EST

On Thu, Jul 27, 2006 at 03:40:49AM +0200, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@xxxxxxxx> wrote:
> > But I agree with Arjan - I think the fundamental problem is that cpu
> > hotplug locking is just is fundamentally badly designed as-is. There's
> > really very little point to making it a _lock_ per se, since most
> > people really want more of a "I'm using this CPU, don't try to remove
> > it right now" thing which is more of a ref-counting-like issue.
> we'd also need a facility to wait on that refcount - i.e. a waitqueue.
> Which means we'd have a "refcount + waitqueue", which is equivalent to a
> "recursive, sleeping read-lock", where the write-side could be used as a
> simple facility to "wait for all readers to go away and block new
> readers from entering the critical sections". [which type of lock Linux
> does not have right now. rwsems come the closest but they dont recurse.]

sounds like some varient of conditional variables, caveat might be that
new readers permitted if in the same call thread/cpu?
(i.e recurive inside the same context?)

for e.g with the cpufreq kind of usage today,

waits for ref to drop to zero;
// now signalled by last reader when refcnt drops to 0
do pre-remove-notify---> cpufreq
// this attempt to acquire read lock again shoudnt be blocked right
// even though we have officially started waiting for cnt to drop 0?

problem was with the kondemand() when a remove_wq() caused a flush_wq()
that started to yeild and run the other wq thread. Now the depth control
that checked if the locking_task == current wasnt true that caused the
dead lock again.

> Also, the hotplug lock is global right now which is pretty unscalable,
> so the rw-mutex should also be per-CPU, and the hotplug locking API
> should be changed to something like:
> cpu = cpu_hotplug_lock();

so this is sort of like the get_cpu()/put_cpu() interface that does
preempt_disable() + get current cpu.

Ashok Raj
- Open Source Technology Center
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at