Re: [Patch][RFC] epoll and half closed TCP connections

[Jamie Lokier]

David Schwartz wrote:
> 	This is really just due to bad coding in 'poll', or more precisely very bad
> for this case. For example, why is it allocating a wait queue buffer if the
> odds that it will need to wait are basically zero? Why is it adding file
> descriptors to the wait queue before it has determined that it needs to
> wait?

Pfeh!  That's just tweaking.

If you really want to optimise 'poll', maintain a per-task event
interest set like epoll does (you could use the epoll infrastructure),
and on each call to 'poll' just apply the differences between the
interest set and whatever is passed to poll.

That would actually reduce the number of calls to per-fd f_op->poll()
methods to O(active), making the internal overhead of 'poll' and
'select' comparable with epoll.

I'd not be surprised if someone has done it already.  I heard of a
"scalable poll" patch some years ago.

That leaves the overhead of the API, which is O(interested) but it is
a much lower overhead factor than the calls to f_op->poll().

Enjoy,
-- Jamie