[lkml]   [2010]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/4, v2] x86: enlightenment for ticket spin locks - base implementation
    On Wed, 2010-06-30 at 10:00 +0100, Jan Beulich wrote:
    > >>> On 30.06.10 at 10:05, Peter Zijlstra <> wrote:
    > > On Tue, 2010-06-29 at 15:31 +0100, Jan Beulich wrote:
    > >> Add optional (alternative instructions based) callout hooks to the
    > >> contended ticket lock and the ticket unlock paths, to allow hypervisor
    > >> specific code to be used for reducing/eliminating the bad effects
    > >> ticket locks have on performance when running virtualized.
    > >
    > > Uhm, I'd much rather see a single alternative implementation, not a
    > > per-hypervisor lock implementation.
    > How would you imaging this to work? I can't see how the mechanism
    > could be hypervisor agnostic. Just look at the Xen implementation
    > (patch 2) - do you really see room for meaningful abstraction there?

    I tried not to, it made my eyes bleed..

    But from what I hear all virt people are suffering from spinlocks (and
    fair spinlocks in particular), so I was thinking it'd be a good idea to
    get all interested parties to collaborate on one. Fragmentation like
    this hardly ever works out well.

    > Not the least that not every hypervisor may even have a way to
    > poll for events (like Xen does), in which case a simple yield may be
    > needed instead.

    No idea what you're talking about, I think you assume I actually know
    something about Xen or virt..

    > >> For the moment, this isn't intended to be used together with pv-ops,
    > >> but this is just to simplify initial integration. The ultimate goal
    > >> for this should still be to replace pv-ops spinlocks.
    > >
    > > So why not start by removing that?
    > Because I wouldn't get around to test it within the time constraints
    > I have?

    I'd say that removing basically dead code (the paravirt spinlocks) the
    code you'd be changing was easier to follow and thus your patches would
    be done quicker?

    > >> +#define ALTERNATIVE_TICKET_LOCK \
    > >
    > > But but but, the alternative isn't a ticket lock..!?
    > ??? Of course it is.

    Ah, right, after looking a bit more at patch 2 I see you indeed
    implement a ticket like lock. Although why you need both a ticket and a
    FIFO list is beyond me.

     \ /
      Last update: 2010-06-30 11:15    [W:0.021 / U:10.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site