Messages in this thread | | | From | Hubertus Franke <> | Subject | Re: [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores) | Date | Tue, 12 Mar 2002 09:56:42 -0500 |
| |
On Tuesday 12 March 2002 02:20 am, Rusty Russell wrote: > In message <Pine.LNX.4.33.0203111441120.17864-100000@penguin.transmeta.com> > you > > write: > > On Sat, 9 Mar 2002, Rusty Russell wrote: > > > > So I would suggest making the size (and thus alignment check) of > > > > locks at least 8 bytes (and preferably 16). That makes it slightly > > > > harder to put locks on the stack, but gcc does support stack > > > > alignment, even if the cod > > e > > > > > sucks right now. > > > > > > Actually, I disagree. > > > > > > 1) We've left wiggle room in the second arg to sys_futex() to add > > > rwsems later if required. > > > 2) Someone needs to implement them and prove they are superior to the > > > pure userspace solution. > > > > You've convinced me. > > Damn. Because now I've been playing with a different approach. > > If we basically export "add_to_waitqueue", "del_from_waitqueue", > "wait_for_waitqueue" and "wakeup_waitqueue" syscalls, we have a more > powerful interface: the kernel need not touch userspace addresses at > all (no kmap/kunmap, no worried about spinlocks vs. rwlocks). > > The problem is that this fundamentally requires at least two syscalls > in the slow path (add_to_waitqueue, try for lock, wait_for_waitqueue). > My tests here show it's about 6% slower than the solution you accepted > for tdbtorture (which means the slow path is significantly slower). I > can't imagine shaving that much more off it. > > There are variations on this: cookie could be replaces the page struct > and the offset, ala futexes. > > Thoughts? > Rusty. > > PS. Kudos: it was Ben LaHaise's idea to export waitqueues, but I > didn't see how to do it until Paul M made a bad joke about two > syscalls....
Rusty, aren't you now going back to the design that I implemented after Ben's comments. From the get-go, I never touched the user address in the kernel, as I thought it would require detailed knowledge of the user level locking strategy.
Could you explain, why you need add_to_waitqueue and wait_for_waitqueue as separate calls ? Is it for resolving a race conditions ?
One comment with respect to multiple wait queues and rwsems: Again it will allow you to do reader-pref and/or writer-pref, but not something like FIFO, i.e. wake up a writer if first waiter or wake up all readers if first ..... and so on. I don't know whether the latter is terrible important ...
-- -- Hubertus Franke (frankeh@watson.ibm.com) - 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/
| |