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/