lkml.org 
[lkml]   [2003]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [Patch][RFC] epoll and half closed TCP connections
Date

> "David Schwartz" <davids@webmaster.com> writes:

> > 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?

> Because this is much easier to do in userspace, it's just not very
> well documented that you should almost always call poll() with a zero
> timeout first.

It's neither easier to do nor harder, it's basically the same code in
either place. However, doing it in kernel space saves the extra user/kernel
transition, poll set allocations, and copies across the u/k boundary in the
case where we do actually need to wait.

> However it's been there for years, and things have used
> it[1].

The thing is, for some reason it (it being the cost of calling poll with a
constant timeout for 1,024 file descriptors) is exceptionally bad on Linux.
Worse than every other OS I've tested.

> There are still optimizations that could have been done to poll() to
> speed it up but Linus has generally refused to add them.

Yep, so we invent new APIs to fix the deficiencies in the most common API's
implementation. Whatever.

DS


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.110 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site