Julian Anastasov wrote:
> ... I think we
> even don't need to fallback to poll() on SIGIO. I use large
> value for the rt queue size (rtsig-max). But may be the overflow can
> happen on very busy host? Is there any reason rtsig-max to be
> greater than num_possible_sock_events*num_of_possible_async_fd in
> current list of supported events ? I.e. for sockets:
> 2 events (read/write) * 32768 sockets = 65536 ? If I use up to
> 32768 async fds I need to setup the rtsig-max=65536. If we use
> sigwaitinfo() together with the proper socket calls we can't
> have more enqueued events? Is this correct? I still didn't tested
> how the kernel performs with long rt queue. If we never reach the
> rtsig-max why should I need to wait for SIGIO?
The kernel might perform poorly with very long rt queues. At
least in 2.2, it does linear scans of the RT queue in
dequeue_signal(). You're better off handling the SIGIO fallback
for now, I think.
- Dan
-
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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:28 EST