Messages in this thread | | | Date | Mon, 17 May 1999 21:15:13 -0700 | From | "David S. Miller" <> | Subject | Re: Why 'wait queues' and not 'channels' |
| |
Date: Mon, 17 May 1999 14:12:41 +0100 (BST) From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unlike Linux, though, it does keep a hash of wait queues.
What is the hash for? The waitqueue is just "there", there is nothing to look up, at least in the Linux case where we build the (small) current task wait queue on the local stack.
I suppose this is where "optimizations" like Solaris's turnstiles and these mentioned hash queues come from, when the design at it's core is where the real problem is. These hacks are just bolted on top.
Some people may argue that the Linux method eats up stack space, it's a mere 16 bytes or so, and in my mind a non-issue. It's also preferable to do things this way because you naturally get cache locality on the current process's kernel stack, and you have to touch that memory anyways in nearly all cases.
In this light I suppose schemes such as the Solaris turnstile mechanism have all sorts of heuristics to make turnstiles be (re-)used on the same processor. Quite a bit of wasted effort, when one considers that this problem solves itself in the Linux scheme.
Finally, the biggest punch line in the DUX implementation seems to be the passing of "why you've been woken up" information. If you're sleeping on a waitqueue, and you don't know why you've been wake up, you have big problems or you need to rearchitect the data structures to use other wait queues if discrete state is not obtainable any other way (I guess if waitqueues are large and expensive this is an issue) :-)
Later, David S. Miller davem@redhat.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |