On Thu, 2009-05-07 at 13:19 +0300, Avi Kivity wrote: > Christian Borntraeger wrote: > >> Why can't this be done from the timer context (after adjusting the locks)? > >> > > > > It can be done, in fact I did that in my first version. The thing is, we > > would need to change all local_int.locks to spinlock_irqs, since standard > > timers are softirqs and hrtimers and hardirqs. Enabling and disabling irqs > > is a relatively expensive operating on s390 (but locks via compare and swap > > are quite cheap). Since we take this specific lock in lots of places this > > lock is on some hot pathes. The idle wakeup on the other hand is not that > > critical. > > > > Makes sense. > > Back when irqsave/irqrestore were expensive on x86 (P4 days, I think it > was ~100 cycles) there was talk of using a software irq disable flag > instead of using the hardware support. So > > - local_irq_disable() sets a flag > > - interrupt handlers check the flag, if set they schedule the interrupt > handler and return immediately > > - local_irq_restore() clears the flag and fires and scheduled handlers > > Now these operations are pretty cheap on x86, but maybe that can apply > to s390.
I don't know how the cycle counts compare, but FWIW normal ppc64 Linux does almost exactly this (and calls it "lazy irq disabling"). The only difference is a step 2.5 that really disables interrupts, because some are level-triggered. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
