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

    \
     
     \ /
      Last update: 2006-11-24 09:37    [W:0.023 / U:61.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site