* i8259 and IO-APIC @ 2002-05-22 9:31 Eric Lemoine 2002-05-27 12:35 ` Terje Eggestad 0 siblings, 1 reply; 6+ messages in thread From: Eric Lemoine @ 2002-05-22 9:31 UTC (permalink / raw) To: linux-kernel I already asked this question but did not get any responses. Please condider answering. Using the old i8259 interrupts controller, my 1-way Linux2.4.16 box livelocks when receiving a high rate UDP flow (interrupt rate is so high that the NET_RX_SOFTIRQ never gets the chance to pull the packets off the backlog queue). However, the receive livelock phenomenom completely disappears when making use of the IO-APIC. Does anyone have an explanation for this? TIA -- Eric ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i8259 and IO-APIC 2002-05-22 9:31 i8259 and IO-APIC Eric Lemoine @ 2002-05-27 12:35 ` Terje Eggestad 2002-05-27 14:27 ` Alan Cox 0 siblings, 1 reply; 6+ messages in thread From: Terje Eggestad @ 2002-05-27 12:35 UTC (permalink / raw) To: Eric Lemoine; +Cc: linux-kernel Hmmm I'm a bit curious my self, in theory the IO_APIC should drastically reduce interrupt latency. An x86 has two interrupt pins, IRQ and NMI. The first 8259 are (if remember correctly) connected to the IRQ only, and the second is connected to IRQ2 on the first 8259 (cascade). When an Int is triggered the CPU has to go out and read the registers in the two 8259's to find the triggered interrupt, and call the corresponding int handler. THe thing is that the 8259 of today are located in the south bridge, and there are an internal ISA bus in the south bridge, but still running at the amazing speed in 10MHz. THe IO-APIC, when used, the CPU is set to use the two IRQ pins (IRQ, and NMI) as a two bit bus, and the IO_APIC send the interruot vector on this bus, saving the CPU from reading the vector over the slow ISA bus, and can call the interrupt directly. However, I've on a couple of occations tried to measure the interrupt latency and I end up with that the latency is the same either I use 8259 or APIC. Most likely a problem with my measuring. Especially since you see better thruput using APIC. However I would like to see you get the same results with a different NIC. Now, if our UDP packetloss are due to bursts, and not sustained traffic, and you have a NIC that uses memory descriptors (like Intel eepro100 chips, or 3com 90x, most new chips do), you can do a workaround by increasing the receive ring size in the driver. TJ On Wed, 2002-05-22 at 11:31, Eric Lemoine wrote: > I already asked this question but did not get any responses. Please > condider answering. > > Using the old i8259 interrupts controller, my 1-way Linux2.4.16 box > livelocks when receiving a high rate UDP flow (interrupt rate is so > high that the NET_RX_SOFTIRQ never gets the chance to pull the > packets off the backlog queue). However, the receive livelock > phenomenom completely disappears when making use of the IO-APIC. > Does anyone have an explanation for this? > > TIA > -- > Eric > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i8259 and IO-APIC 2002-05-27 12:35 ` Terje Eggestad @ 2002-05-27 14:27 ` Alan Cox 2002-05-27 14:35 ` Terje Eggestad 0 siblings, 1 reply; 6+ messages in thread From: Alan Cox @ 2002-05-27 14:27 UTC (permalink / raw) To: Terje Eggestad; +Cc: Eric Lemoine, linux-kernel On Mon, 2002-05-27 at 13:35, Terje Eggestad wrote: > I'm a bit curious my self, in theory the IO_APIC should drastically > reduce interrupt latency. An x86 has two interrupt pins, IRQ and NMI. The APIC reduces processing overhead. The APIC bus on the pentium III is pretty slow (I believe its a serial 4 wire bus or similar). On the Athlon and Pentium IV it seems to be a lot faster. In the case of a livelock the problem is probably the cost of handling the IRQ and poking slowly at the chip. Latency is pretty immaterial here compared with irq servicing overheads. Alan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i8259 and IO-APIC 2002-05-27 14:27 ` Alan Cox @ 2002-05-27 14:35 ` Terje Eggestad 2002-05-27 15:59 ` Zwane Mwaikambo 2002-05-27 17:34 ` Alan Cox 0 siblings, 2 replies; 6+ messages in thread From: Terje Eggestad @ 2002-05-27 14:35 UTC (permalink / raw) To: Alan Cox; +Cc: Eric Lemoine, linux-kernel On Mon, 2002-05-27 at 16:27, Alan Cox wrote: > On Mon, 2002-05-27 at 13:35, Terje Eggestad wrote: > > I'm a bit curious my self, in theory the IO_APIC should drastically > > reduce interrupt latency. An x86 has two interrupt pins, IRQ and NMI. > > The APIC reduces processing overhead. The APIC bus on the pentium III is > pretty slow (I believe its a serial 4 wire bus or similar). On the > Athlon and Pentium IV it seems to be a lot faster. > > In the case of a livelock the problem is probably the cost of handling > the IRQ and poking slowly at the chip. Latency is pretty immaterial here > compared with irq servicing overheads. Do you got any numbers that state that it's processing overhead, and not HW latency that is the bulk of interrupt service time? Just curious, I've been looking and can't find this "perceived fact" backed up by facts anywhere. BTW: according to "IA-32 Intel Arch. Software Developer's Man Vol 3" both P3 and P4 the APIC bus is three wire, two data and one clock. > > Alan TJ -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i8259 and IO-APIC 2002-05-27 14:35 ` Terje Eggestad @ 2002-05-27 15:59 ` Zwane Mwaikambo 2002-05-27 17:34 ` Alan Cox 1 sibling, 0 replies; 6+ messages in thread From: Zwane Mwaikambo @ 2002-05-27 15:59 UTC (permalink / raw) To: Terje Eggestad; +Cc: Alan Cox, Eric Lemoine, linux-kernel On 27 May 2002, Terje Eggestad wrote: > Do you got any numbers that state that it's processing overhead, and not > HW latency that is the bulk of interrupt service time? Just curious, > I've been looking and can't find this "perceived fact" backed up by > facts anywhere. I think Alan had the ISR and kernel IRQ service overhead in mind. In this light, hardware interrupt latency is a drop in the ocean.. Cheers, Zwane Mwaikambo -- http://function.linuxpower.ca ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i8259 and IO-APIC 2002-05-27 14:35 ` Terje Eggestad 2002-05-27 15:59 ` Zwane Mwaikambo @ 2002-05-27 17:34 ` Alan Cox 1 sibling, 0 replies; 6+ messages in thread From: Alan Cox @ 2002-05-27 17:34 UTC (permalink / raw) To: Terje Eggestad; +Cc: Eric Lemoine, linux-kernel On Mon, 2002-05-27 at 15:35, Terje Eggestad wrote: > Do you got any numbers that state that it's processing overhead, and not > HW latency that is the bulk of interrupt service time? Just curious, > I've been looking and can't find this "perceived fact" backed up by > facts anywhere. It depends what the interrupt actually does. What I was saying is that the processing overhead is what hurts not the latency. If you think about a continual stream of events latency on the busses effectively skews the delivery time of the interrupt but not the rate of processing. > BTW: according to "IA-32 Intel Arch. Software Developer's Man Vol 3" > both P3 and P4 the APIC bus is three wire, two data and one clock. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-05-27 16:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-05-22 9:31 i8259 and IO-APIC Eric Lemoine 2002-05-27 12:35 ` Terje Eggestad 2002-05-27 14:27 ` Alan Cox 2002-05-27 14:35 ` Terje Eggestad 2002-05-27 15:59 ` Zwane Mwaikambo 2002-05-27 17:34 ` Alan Cox
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox