Messages in this thread | | | Date | Tue, 16 Nov 1999 20:05:37 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Signal driven IO |
| |
From: "David Schwartz" <davids@webmaster.com> Date: Tue, 16 Nov 1999 15:12:00 -0800
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/
| |