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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
