lkml.org 
[lkml]   [1999]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.133 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site