Jordan Mendelson ([EMAIL PROTECTED]) wrote:
> An implementation of /dev/poll for Linux already exists and has shown to
> be more scalable than using RT signals under my tests. A patch for 2.2.x
> and 2.4.x should be available at the Linux Scalability Project @
> http://www.citi.umich.edu/projects/linux-scalability/ in the patches
> section.
If you'll look at the page I linked to in my original post,
http://www.kegel.com/dkftpbench/Poller_bench.html
you'll see that I also benchmarked /dev/poll.
When finding 1 active fd among 10000, the Solaris implementation creamed the living
snot out of the Linux one, even though the Solaris hardware was 5 or so times slower
(see the lmbench results on that page). Here are the numbers (times in microseconds):
On a 167MHz sun4u Sparc Ultra-1 running SunOS 5.7 (Solaris 7) Generic_106541-11:
pipes 100 1000 10000
select 151 - -
poll 470 676 3742
/dev/poll 61 70 92
On an idle 650 MHz dual Pentium III running Red Hat Linux 6.2 with kernel 2.2.14smp
plus the /dev/poll patch:
pipes 100 1000 10000
select 28 - -
poll 23 890 11333
/dev/poll 19 146 4264
On the same machine as above, but with vanilla kernel 2.4.0-test10-pre4 smp:
pipes 100 1000 10000
select 52 - -
poll 49 1184 14660
> It works fairly well, but I was actually somewhat disappointed to find
> that it wasn't the primary cause for the system CPU suckage for my
> particular system. Granted, when you only have to poll a few times per
> second, the overhead of standard poll() just isn't that bad.
If you have to poll 100 or fewer sockets, Linux's poll is quite good.
If you have to poll 1000 or so sockets, Linux's /dev/poll works well
(I wish it were available for the current kernels).
But if you have to poll 10000 or sockets on Linux,
neither standard poll nor /dev/poll as currently implemented performs adequately.
I suspect that RT signals on Linux will do much better for N=10000 than the
current /dev/poll, and hope to benchmark that soon.
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
