[lkml]   [2002]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] async poll for 2.5
    At 10:18 AM 15/10/2002 -0700, Dan Kegel wrote:
    >Benjamin LaHaise wrote:
    > >
    > > On Tue, Oct 15, 2002 at 10:06:22AM -0700, Dan Kegel wrote:
    > > > Doesn't the F_SETSIG/F_SETOWN/SIGIO stuff qualify as a scalable
    > > > alternative?
    > >
    > > No.
    >What's the worst part about it? The use of the signal queue?

    there are four things that really suck about sigio.
    in order of most-significant-suckage to least-significant-suckage, i see
    them as:

    [1] signals are very heavy.
    thousands of signals/second does not scale on SMP due to the
    serialization of them in the kernel.
    (just look at the code path for delivering a signal)

    signals also resulted in 128 u32's being transferred from kernel
    to userspace for every signal. thats a lot of memory i/o
    bandwidth consumed at 1000's of concurrent sockets
    and tens-of-thousands of events/sec happening.

    [2] SIGIO only exposes half of the POLL_OUT semantics.
    with poll(), you can use POLL_OUT to indicate if there
    is free buffer space to write into or not.
    with SIGIO, for most applications, you can only find out
    by issuing a write() and get back a -EWOULDBLOCK.
    to indicate !POLL_OUT.
    (perhaps that has been addressed in the last 12 months or so;
    but i doubt it)

    [3] SIGIO had no easy recovery path if you hit the maximum-
    queue-limit for number of signals queued to userspace.
    (ok, you *could* do a poll() and start again, but it couldn't
    be done in a 100% race-free manner)

    [4] you couldn't enable SIGIO on a incoming socket
    accept()ed without there being a race window where
    something happened to that socket between accept() and
    enable-SIGIO. [sort-of related to (3); you could work-around
    it by doing a poll() on the socket after enable-SIGIO, but
    it makes a clean interface a horrible interface]

    other miscellaneous things that makes SIGIO less usable in the real-world:
    - you can only get one event at a time -- that means tens-of-thousands
    to hundreds-of-thousands of system calls / second just to get event
    status, when it'd probably make more sense to poll for multiple signals
    at the same time
    - SIGIO only addressed "event notification". it did nothing to address the
    other large scalability that you typically hit when writing
    high-performance i/o
    systems: overhead of memory-copy from userspace<->kernelspace.
    various zerocopy mechanisms help address that side of thing, but if you're
    comparing aio to SIGIO, aio *is* addressing a much larger problem than just
    SIGIO on its own



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.022 / U:81.560 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site