Date: Fri, 18 Dec 1998 07:39:38 -0800 (PST)
From: Linus Torvalds <[EMAIL PROTECTED]>
Ehh.. Any interrupt is going to be a _lot_ more costly than a few
cross-cpu cache misses.
Not true if interrupts begin getting pushed to that processor. When a
processor becomes an "interrupt worker" as a result of idling a bit
(because my scheme pushes active interrupts proactively to him, and
the IO_APIC even how you program it now on x86 will do this) he
isolates the rest of the system from interrupt related bus traffic.
These idler cpus take the misses and go out to the bus, not the other
cpus who potentially have a decent sized data set hot in their caches.
This cpu will obtain the resident set of the interrupt handlers most
likely, and then the majority traffic he generates will be the PIOs to
the devices he is servicing.
I can prove this. The performance counters on the Ultra, unless
broken, support my claims completely. With idler IRQ forwarding on
and the heuristics in the idler, system wide cache misses went down
substantially (12% on average with about ~2 of error between test
runs). Even outside of the controlled tests I performed, similar
gains were shown when I measured the effects during real work,
parallel builds, a process writing to a disk continuously, large
tranfers over 100baseT TCP etc.
I really don't think I'm solving a non-problem in the back of an OS
textbook. :-)
We could add the test for "current->need_resched" and only call the
scheduler then. I think Andrea did that. Fell free to send me timings, but
I don't want to change the scheduler just because somebody _thinks_ it
makes a difference.
I am rather certain that adding simple heuristics such as I have
suggested to the idler loop does in fact make a difference.
Later,
David S. Miller
[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
