I was reading through "FreeBSD Versus Linux Revisited" by Moshe Bar at "http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html".
One paragraph in particular caught my eye:
On the Linux side, I attached all interrupts coming
from the network adaptor to one CPU. With the new
TCP/IP stack in the 2.4 kernels this really becomes
necessary. Otherwise, you might find the incoming
packets arranged out of order, because later interrupts
are serviced (on another CPU) before earlier ones, thus
requiring a reordering further down the handling layers.
Is this a widely-known issue? Or is this simply theory? I'd never heard this mentionned until I read the article.
I ran some web-based performance tests with the 2.4.19-pre9-SMP kernel on a dual-CPU Athlon 1600MHz box, and found that running with "noapic" actually improved network performance. (Negligable -- only 1% improvement in the small webstone-based test I ran.)
As I wrote in another post concerning performance from earlier today, the actual values of my performance tests are not important -- the trend is what I wish to higlight.
My questions are:
1) am I right in thinking that "noapic" will force all interrupts to be handled by 1 CPU?
2) how would you force all interrupts from only 1 hardware device (and not all devices) to be handled by 1 processor, as hinted in the paragraph quoted above?
Thanks,
Stephane Charette
Stephane Charette wrote:
>
> My questions are:
>
> 1) am I right in thinking that "noapic" will force all interrupts to be handled by 1 CPU?
Yes.
>
> 2) how would you force all interrupts from only 1 hardware device (and not all devices) to be handled by 1 processor, as hinted in the paragraph quoted above?
echo "00000001" > /proc/irq/19/smp_affinity
Will cause irq 19 to be serviced by processor 1
echo "00000003" > /proc/irq/19/smp_affinity
Will allow irq 19 to be serviced by processor 1 and 2
You could also do this in the driver if you wanted.
Note that this will not work when noapic is used..
Mark