> 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
We have cache affinity already. The scheduler does the work for us. There is
certainly scope for pulling tricks like when we do I/O involving copies to
userspace from networking we switch the cpu that task allegedly last ran on
to be the CPU that blasted all the data into memory
Because NT Completion ports work at a higher level (with all the
advantages and disadvantages associated with this), it means that their
scheduler has more information to work with in order to get better cache
affinity. If you have 10 worker threads processing 100 active
connections, NT can schedule the correct worker thread that had been
previously working with a particular connection. We would have to put
some fairly nasty kludges into the RT SIGIO framework to be able to do a
similar thing. A similar issue is that real-time signals are delievered
in FIFO order, and there are times when that's not ideal for efficiency
(although granted LIFO definitely is a problem as far as fairness is
concerned, and on an overloaded system it's possible for a connection to
be never serviced.)
- 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/