[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Xen spinlock questions
Jeremy, considering to utilize your pv-ops spinlock implementation for our kernels, I'd appreciate your opinion on the following thoughts: 1) While the goal of the per-CPU kicker irq appears to be to avoid all CPUs waiting for a particular lock to get kicked simultaneously, I think this doesn't have the desired effect. This is because Xen doesn't track what event channel you poll for (through SCHEDOP_poll), and rather kicks all CPUs polling for any event channel. 2) While on native not re-enabling interrupts in __raw_spin_lock_flags() may be tolerable (but perhaps questionable), not doing so at least on the slow path here seems suspicious. 3) Introducing yet another per-CPU IRQ for this purpose further tightens scalability. Using a single, IRQF_PER_CPU IRQ should be sufficient here, as long as it gets properly multiplexed onto individual event channels (of which we have far more than IRQs). I have a patch queued for the traditional tree that does just that conversion for the reschedule and call-function IPIs, which I had long planned to get submitted (but so far wasn't able to due to lack of testing done on the migration aspects of it), and once successful was planning on trying to do something similar for the timer IRQ. I am attaching that (2.6.26 based) patch just for reference. Thanks, Jan Attachment:
xen-ipi-per-cpu-irq.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |