[lkml]   [2010]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] use unfair spinlock when running on hypervisor.
    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).

    Do you want to comment on this?

    - vatsa

     \ /
      Last update: 2010-06-03 16:51    [W:0.027 / U:200.808 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site