Linus Torvalds wrote:
> Dan Kegel wrote:
>> [ http://www.kegel.com/dkftpbench/Poller_bench.html ]
>> [ With only one active fd and N idle ones, poll's execution time scales
>> [ as 6N on Solaris, but as 300N on Linux. ]
>
> Basically, poll() is _fundamentally_ a O(n) interface. There is no way
> to avoid it - you have an array, and there simply is _no_ known
> algorithm to scan an array in faster than O(n) time. Sorry.
> ...
> Under Linux, I'm personally more worried about the performance of X etc,
> and small poll()'s are actually common. So I would argue that the
> Solaris scalability is going the wrong way. But as performance really
> depends on the load, and maybe that 10000 entry load is what you
> consider "real life", you are of course free to disagree (and you'd be
> equally right ;)
I don't think I was being as clueless as you feared.
Solaris' poll() somehow manages to skip inactive fd's very efficiently.
But I'm happy to agree that small poll()'s are very important.
I'd prefer to never use big poll()'s. The RT signal stuff
scales much better.
I'm trying to write a server that handles 10000 clients. On 2.4.x,
the RT signal queue stuff looks like the way to achieve that.
Unfortunately, when the RT signal queue overflows, the consensus seems
to be that you fall back to a big poll(). And even though the RT signal
queue [almost] never overflows, it certainly can, and servers have to be
able to handle it.
The way I'm implementing RT signal support is by writing a userspace
wrapper to make it look like an OO version of poll(), more or less,
with an 'add(int fd)' method so the wrapper manages the arrays of pollfd's.
When and if I get that working, I may move it into the kernel as an
implementation of /dev/poll -- and then I won't need to worry about
the RT signal queue overflowing anymore, and I won't care how scalable
poll() is.
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:22 EST