up to 50% faster sys_poll()

PATCH Dan Kegel 1 participant 2 messages Jan 6, 2001 – Jan 7, 2001

Share & tools

Dan Kegel

author

2001-01-06 21:57 UTC #0 lore raw

Quoted 6 lines · Manfred

sys_poll spends around 1/2 of the execution time allocating / freeing a few bytes temporary memory.
The attached patch tries to avoid these allocation by using the stack - usually only a few bytes are needed, kmalloc is used for the rest. The result: one poll of stdin is down from 1736 cpu ticks to 865 cpu ticks (Pentium II/350 SMP, SMP kernel)

Tested with poll() microbenchmark from
http://www.kegel.com/dkftpbench/Poller_bench.html

time in microsec to find a single active pipe among N pipes on a 650 MHz dual Pentium III using poll():

number of pipes
kernel 100 1000 10000
---------------------------------

2.4.0-t10pre4  49    1184   14660
2.4.0          48    1162   14702
2.4.0-pp       48    1103   14205

2.4.0-pp is with Manfred's patch. Seems to be a 4-6% improvement for large numbers of pipes, no change for 100 pipes.

Hope that was an appropriate test.

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

Dan Kegel

author

2001-01-07 00:17 UTC #1 lore raw

Quoted 8 lines · Manfred

The improvement with large number of pipes probably comes from replacing __get_free_page() with kmalloc() - kmalloc is faster, especially on SMP.
...
I expected 2 improvements:
* poll with < 24 descriptors: around 800 cpu ticks faster, but that's just one or two microseconds.
* if one of the first 8 descriptors has new data: add another ~200 cpu ticks.

OK, I reran with different numbers of fd's, again on a 650 MHz dual PIII SMP.

Times in microseconds to find 1 active pipe out of N total pipes:

number of pipes
kernel 1 8 10000 30000
-----------------------------------------

2.4.0         7     10      14600   45843
2.4.0-pp      5      8      14321   44903

For small N, your patch makes poll() 2 microseconds faster uniformly. That's a 20-30% speedup, not bad.
Anyone know if this would actually help real-life programs?

BTW, your change makes poll() slightly faster than select().

For large N, your patch speeds poll() up by 2-5%.
(Increasing /proc/sys/fs/file-max to 70000 appears to reduce the speedup.) I doubt that will have much effect on real-life programs.
- 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/