Re: [take25 1/6] kevent: Description.

From: Eric Dumazet
Date: Fri Nov 24 2006 - 03:40:04 EST


Andrew Morton a écrit :
On Fri, 24 Nov 2006 01:48:32 +0100
Eric Dumazet <dada1@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/