On Thu, Jun 03, 2010 at 11:45:00PM +1000, Nick Piggin wrote: > > Ok got it - although that approach is not advisable in some cases for ex: when > > the lock holder vcpu and lock acquired vcpu are scheduled on the same pcpu by > > the hypervisor (which was experimented with in [1] where they foud a huge hit in > > perf). > > Sure but if you had adaptive yielding, that solves that problem. I guess so. > > Oops you are right - sorry should have checked more closely earlier. Given that > > we may not be able to always guarantee that locked critical sections will not be > > preempted (ex: when a real-time task takes over), we will need a combination of > > both approaches (i.e request preemption defer on lock hold path + yield on lock > > acquire path if owner !scheduled). The advantage of former approach is that it > > could reduce job turnaround times in most cases (as lock is available when we > > want or we don't have to wait too long for it). > > Both I think would be good. It might be interesting to talk with the > s390 guys and see if they can look at ticket locks and preempt defer > techniques too (considering they already do the other half of the > equation well). Martin/Heiko, Do you want to comment on this? - vatsa -- 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
