Messages in this thread | | | Date | Sat, 29 Jul 2006 15:45:27 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Reorganize the cpufreq cpu hotplug locking to not be totally bizare |
| |
* Ashok Raj <ashok.raj@intel.com> wrote:
> On Thu, Jul 27, 2006 at 03:40:49AM +0200, Ingo Molnar wrote: > > > > * Linus Torvalds <torvalds@osdl.org> 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?
well, i'd just call it a recursive rwsem. (sure, you can express it via condition variables, but just about any locking method can be expressed via them.)
> > 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.
the API is similar - behavior is different in that the 'per-cpu lock' i'm talking about _does_ allow preemption and migration to another CPU.
Ingo - 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/
| |