On Mon, Oct 23, 2000 at 06:16:24PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 24 Oct 2000, Andi Kleen wrote:
> >
> > It would be possible to setup a file -> fdnum reverse table (possibly cached
> > over poll calls, I think Solaris does that) and let the async events directly
> > change the bits in the output buffer in O(1).
>
> I disagree.
>
> Let's just face it, poll() is a bad interface scalability-wise.
It is, but Linux poll is far from being a good implementation even in the
limitations of the interfaces, as the comparison with Solaris shows. It is
inherently O(n), but the constant part of that in Linux could be certainly
improved.
Also with the poll table mmap'ed via /dev/poll and the optimizations I
described poll could be made quite nice (I know that queued SIGIO exists,
but it has its drawbacks too and often you need to fallback to poll anyways)
>
> > Also the current 2.4 poll is very wasteful both in memory and cycles
> > for small numbers of fd.
>
> Yes, we could go back to the "optimize the case of n < 8" thing. Which
> should be particularly easy with the new "poll_table_page" setup: the
> thing is more abstracted than it used to be in 2.2.
I did it for n < 40. It also put the wait queues on the stack, in that
it is even more efficient than 2.0
I attached the patch for your reference, it is against test3 or so
(but iirc select/poll has not changed after that). I'm not proposing it
for inclusion right now.
It does only the easy parts of course, I think with some VFS extensions
it could be made a lot better.
BTW the linux select can be get a lower constant part of n too by simply
testing whole words of the FD_SET for being zero and skipping them quickly
(that makes it a lot cheaper when you have bigger holes in the select fd
space). The patch does that too.
-Andi
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:22 EST