Messages in this thread |  | | | Date | Fri, 24 Nov 2006 09:33:12 +0100 | | From | Eric Dumazet <> | | Subject | Re: [take25 1/6] kevent: Description. |
| |
Andrew Morton a écrit : > On Fri, 24 Nov 2006 01:48:32 +0100 > Eric Dumazet <dada1@cosmosbay.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |