Hello!
> it looks as though _every_ TCP ACK you receive will cause epoll to wake up
> a task which is interested in _any_ socket events,
This is not quite true. sk->write_space() is called only after write
queue is full, and it is exactly one wakeup until the next overflow.
But, actually, yes, it is right observation: one wait queue for all
the socket events is painful. Note, that with current poll() improvements
are suboptimal, tcp_poll() does not know _what_ this poll polls for,
so it has to stand in all the wait queues. The same thing kills lots
of possible improvements.
> further, we might as well admit that POLLHUP should be called
> POLLWRHUP.)
No, really. POLLHUP=POLLRDHUP&POLLWRHUP, plus POLLHUP is unmaskable event.
Yes, SVR4 screwed up its semantics in such extent that it is mostly
meaningless.
Alexey
On Mon, 14 Jul 2003 [email protected] wrote:
> > it looks as though _every_ TCP ACK you receive will cause epoll to wake up
> > a task which is interested in _any_ socket events,
>
> This is not quite true. sk->write_space() is called only after write
> queue is full, and it is exactly one wakeup until the next overflow.
>
> But, actually, yes, it is right observation: one wait queue for all
> the socket events is painful. Note, that with current poll() improvements
> are suboptimal, tcp_poll() does not know _what_ this poll polls for,
> so it has to stand in all the wait queues. The same thing kills lots
> of possible improvements.
Indeed. This can be improved though, with some serious work. The poll(2)
and epoll caller supply events he is interested in. We could have
poll_wait() (and f_op->poll()) to accept an events parameter so that the
f_op->poll() code can drop inside separate wait queue depending on what
the caller is waiting for.
- Davide