Date: Mon, 14 Jul 2003 11:25:49 -0700 (PDT)
From: Davide Libenzi <davidel@xmailserver.org>
To: kuznet@ms2.inr.ac.ru
cc: "David S. Miller" <davem@redhat.com>, jmorris@redhat.com,
       jamie@shareable.org,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Fw: Re: [Patch][RFC] epoll and half closed TCP connections
In-Reply-To: <200307141739.VAA05290@dub.inr.ac.ru>
Message-ID: <Pine.LNX.4.55.0307141122260.4828@bigblue.dev.mcafeelabs.com>
References: <200307141739.VAA05290@dub.inr.ac.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1214
Lines: 29

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

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