* Re: Fw: Re: [Patch][RFC] epoll and half closed TCP connections [not found] <20030713070352.3f21a9f8.davem@redhat.com> @ 2003-07-14 17:39 ` kuznet 2003-07-14 18:25 ` Davide Libenzi 0 siblings, 1 reply; 2+ messages in thread From: kuznet @ 2003-07-14 17:39 UTC (permalink / raw) To: David S. Miller; +Cc: jmorris, jamie, linux-kernel 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 ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Fw: Re: [Patch][RFC] epoll and half closed TCP connections 2003-07-14 17:39 ` Fw: Re: [Patch][RFC] epoll and half closed TCP connections kuznet @ 2003-07-14 18:25 ` Davide Libenzi 0 siblings, 0 replies; 2+ messages in thread From: Davide Libenzi @ 2003-07-14 18:25 UTC (permalink / raw) To: kuznet; +Cc: David S. Miller, jmorris, jamie, Linux Kernel Mailing List On Mon, 14 Jul 2003 kuznet@ms2.inr.ac.ru 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 ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-07-14 18:18 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20030713070352.3f21a9f8.davem@redhat.com> 2003-07-14 17:39 ` Fw: Re: [Patch][RFC] epoll and half closed TCP connections kuznet 2003-07-14 18:25 ` Davide Libenzi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).