> "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/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:01:01 EST