Andrew Morton a écrit :
On Fri, 24 Nov 2006 01:48:32 +0100
Eric Dumazet <[email protected]> wrote:
The alternative is the sorry state we have now. In nscd, for instance,
we have one single thread waiting for incoming connections and it then
has to wake up a worker thread to handle the processing. This is done
because we cannot "park" all threads in the accept() call since when a
new connection is announced _all_ the threads are woken. With the new
event handling this wouldn't be the case, one thread only is woken and
we don't have to wake worker threads. All threads can be worker threads.
Having one specialized thread handling the distribution of work to worker
threads is better most of the time.
It might be now. Think "commodity 128-way". Your single distribution thread
will run out of steam.
What Ulrich is proposing is faster. This is a new interface. Let's design
it to be fast.
Hum... I guess you didnt read my mail... I basically agree with Ulrich.
I just wanted to say that a fast application cannot rely only on a "let's park
N threads waiting for single event in this queue", and hope kernel will be
smart for us.
Even with 128-ways, you still hit a central point of coordination (it can be a
mutex in kevent code, a atomic uidx in userland, or whatever) for a 'kevent
queue'. Once you paid the cache lines ping/pong, you wont be *fast*.
I wish *you* dont think of kevent of only dispatching HTTP 1.0 trivial web
requests.
Being able to direct a particular request on a particular CPU is certainly
something that cannot be hardcoded in 'the new kevent interface'.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
