lkml.org 
[lkml]   [1999]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: Signal driven IO
    Date
    > 	Is SIGIO somehow guaranteed to be queued?  The reason the
    > kernel sends SIGIO is because there is no more room to queue
    > signals, right?
    >
    > Also, the wouldn't it be better to _lose_ an event (and
    > possibly leave a connection in limbo) than to spend the time
    > to poll 10k+ sockets? Remember, you are going to be _heavily_
    > loaded before you start seeing SIGIO.

    Not at all! What a ridiculous thing to say.

    Under such heavy load, poll is more efficient than queued signals. A single
    call to poll with a zero timeout can tell you about thounsands of ready fds
    without just a single kernel/user transition and no memory
    allocations/frees. Queued signals can't touch that.

    > I understand that each thread has it's own signal queue and
    > that you can tune the size of the signal queue via
    > /proc/sys/kernel/rtsig-max. Is that correct? If so, then I
    > can consider the SIGIO as a warning that I need to configure
    > the server with more queue space, or get faster hardware.
    > What do you think?

    No. Switch to poll when enough fds are ready per loop. You want the queue
    size to be set such that you are using signals most of the time, but if you
    should fall behind, and have large numbers of fds ready, you can use the
    more efficient 'mass' poll system call.

    Simply increasing the queue size would cause you to lose this 'best of both
    worlds' aspect. Worse, it would casuse your program to continue to need more
    and more CPU dequeuing more and more signals as load goes up. You'd rather
    make fewer and fewer calls to poll as load goes up, wouldn't you?

    DS


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:4.230 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site