lkml.org 
[lkml]   [2017]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 06/13] lockdep: Implement crossrelease feature
    On Wed, Mar 01, 2017 at 02:43:23PM +0900, Byungchul Park wrote:
    > On Tue, Feb 28, 2017 at 02:40:18PM +0100, Peter Zijlstra wrote:
    > > > +static int commit_xhlocks(struct cross_lock *xlock)
    > > > +{
    > > > + struct task_struct *curr = current;
    > > > + struct hist_lock *xhlock_c = xhlock_curr(curr);
    > > > + struct hist_lock *xhlock = xhlock_c;
    > > > +
    > > > + do {
    > > > + xhlock = xhlock_prev(curr, xhlock);
    > > > +
    > > > + if (!xhlock_used(xhlock))
    > > > + break;
    > > > +
    > > > + if (before(xhlock->hlock.gen_id, xlock->hlock.gen_id))
    > > > + break;
    > > > +
    > > > + if (same_context_xhlock(xhlock) &&
    > > > + before(xhlock->prev_gen_id, xlock->hlock.gen_id) &&
    > > > + !commit_xhlock(xlock, xhlock))
    > > > + return 0;
    > > > + } while (xhlock_c != xhlock);
    > > > +
    > > > + return 1;
    > > > +}
    > >
    > > So I'm still struggling with prev_gen_id; is it an optimization or is it
    > > required for correctness?
    >
    > It's an optimization, but very essential and important optimization.
    >
    > in hlocks[]
    > ------------
    > A gen_id (4) --+
    > | previous gen_id
    > B gen_id (3) <-+
    > C gen_id (3)
    > D gen_id (2)
    > oldest -> E gen_id (1)
    >
    > in xhlocks[]
    > ------------
    > ^ A gen_id (4) prev_gen_id (3: B's gen id)
    > | B gen_id (3) prev_gen_id (3: C's gen id)
    > | C gen_id (3) prev_gen_id (2: D's gen id)
    > | D gen_id (2) prev_gen_id (1: E's gen id)
    > | E gen_id (1) prev_gen_id (NA)
    >
    > Let's consider the case that the gen id of xlock to commit is 3.
    >
    > In this case, it's engough to generate 'the xlock -> C'. 'the xlock -> B'
    > and 'the xlock -> A' are unnecessary since it's covered by 'C -> B' and
    > 'B -> A' which are already generated by original lockdep.
    >
    > I use the prev_gen_id to avoid adding this kind of redundant
    > dependencies. In other words, xhlock->prev_gen_id >= xlock->hlock.gen_id
    > means that the previous lock in hlocks[] is able to handle the
    > dependency on its commit stage.
    >

    Aah, I completely missed it was against held_locks.

    Hurm.. it feels like this is solving a problem we shouldn't be solving
    though.

    That is, ideally we'd already be able to (quickly) tell if a relation
    exists or not, but given how the whole chain_hash stuff is build now, it
    looks like we cannot.


    Let me think about this a bit more.

    \
     
     \ /
      Last update: 2017-03-01 15:46    [W:4.316 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site