[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161130125229.GQ23336@nuc-i3427.alporthouse.com>
Date: Wed, 30 Nov 2016 12:52:29 +0000
From: Chris Wilson <chris@...is-wilson.co.uk>
To: Maarten Lankhorst <dev@...ankhorst.nl>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Nicolai Hähnle <nhaehnle@...il.com>
Subject: Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress
On Wed, Nov 30, 2016 at 01:29:39PM +0100, Maarten Lankhorst wrote:
> > +static void stress_work(struct work_struct *work)
> > +{
> > + struct stress *stress = container_of(work, typeof(*stress), work);
> > + const int nlocks = stress->nlocks;
> > + struct ww_mutex *locks = stress->locks;
> > + struct ww_acquire_ctx ctx;
> > + int contended = -1;
> > + int *order;
> > + int n, ret;
> > +
> > + order = get_random_order(nlocks);
> > + if (!order)
> > + return;
> > +
> > + ww_acquire_init(&ctx, &ww_class);
> > +
> > +retry:
> > + ret = 0;
> > + for (n = 0; n < nlocks; n++) {
> > + if (n == contended)
> > + continue;
> > +
> > + ret = ww_mutex_lock(&locks[order[n]], &ctx);
> > + if (ret < 0)
> > + break;
> > + }
> What's wrong with attempting to lock the contended lock here?
> Who knows, this might find some more bugs than the functional tests already do.
I was trying to follow the guide, which was lock, backoff by unlocking
everything, slowlock the contended lock, then lock everything else.
I have now a second worker that follows the reordering method as well.
(As well as a test that slowlock after the ABBA deadlock detection
resolves the locking order.)
If you have a sketch of something else to try, I'll add it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Powered by blists - more mailing lists