Messages in this thread | | | Date | Sat, 4 Jul 2009 12:26:37 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 1/2] IRQ: fix performance regression on large IA64 systems |
| |
* Jiri Slaby <jirislaby@gmail.com> wrote:
> Commit b60c1f6ffd88850079ae419aa933ab0eddbd5535 > (drop note_interrupt() for per-CPU for proper scaling) removed call to > note_interrupt() in __do_IRQ(). Commit > d85a60d85ea5b7c597508c1510c88e657773d378 > (Add IRQF_IRQPOLL flag (common code)) added it again, because it's needed > for irqpoll. > > This patch now introduces a new parameter 'only_fixup' for > note_interrupt(). This parameter determines two cases: > > TRUE => The function should be only executed when irqfixup is set. > Either 'irqpoll' or 'irqfixup' directly set that. > > FALSE => Just the behaviour as note_interrupt() always had. > > Now the patch converts all calls of note_interrupt() to > only_fixup=FALSE, except the call that has been removed by > b60c1f6ffd. So that call is always done, but the body is only > executed when either 'irqpoll' or 'irqfixup' are specified. > > This is needed because __do_IRQ() calls note_interrupt() to record > IRQ statistics. It ends up creating serious cache line contention, > enough that a 1024p system live locks under the crushing weight of > the timer tick. > > The note_interrupt() call modifies fields in the irq_desc_t > structure. For PER_CPU timer interrupts (on ia64 machines) this > causes cacheline contention. > > Systems with 1024 processors take an extremely long time to boot > up, as most of the time is spent attempting to service timer > interrupts. With noirqdebug added to the boot line, the system > boots in close to the normal amount of time.
What would be the effect/cost of enabling this by default? Seems desirable and eventually we'll hit those problems with regular systems too ...
Ingo
| |