A clear winner regardless of how many file desciptors are ready per "loop
pass"? Surely there has to be some number at which poll becomes superior.
Certainly with artificial cases where you overload the CPU and deliberately
hit multiple links at the same time.
The measure of this inflection point should be the number of signals
'backed up'. Clearly, if the backup number is 100% of the number of file
descriptors, poll would be better.
It's actually not clear poll() is a win; if you have scenario where you
have multiple threads (possibly on an SMP system), by using signals, you
can quickly and easily dispatch jobs to different worker threads by
simply having different threads picking up the real-time signals.
If you use poll(), you either have to do fancy locking, or you have to
have one threads which does IPC to talk dispatch tasks to each worker
thread, which is not ideal.
One other observation, which an engineer from Netscape (who does IMAP
server implementations for Linux and NT) points out is that NT
completion ports have two features which RT SIGIO doesn't provide. One
is processor affinity; on SMP systems, when a completion port becomes
ready, the system will try to schedule the callback thread on the same
processor which registered the callback originally. The other is thing
which NT does is LIFO ordering when multiple completion ports are to be
scheduled. Both of these strategies are an attempt to avoid cache
misses. I'm not sure how much different these tricks actually make, but
John seem to think it would make a noticeable difference for his
application.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/