[PATCH] randomized delay in locking primitives, take 2
John Baldwin
jhb at freebsd.org
Mon Aug 1 20:21:48 UTC 2016
On Monday, August 01, 2016 10:08:43 PM Mateusz Guzik wrote:
> On Mon, Aug 01, 2016 at 11:37:50AM -0700, John Baldwin wrote:
> > On Sunday, July 31, 2016 02:41:13 PM Mateusz Guzik wrote:
> > > On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote:
> > > [snip]
> > >
> > > After an irc discussion, the following was produced (also available at:
> > > https://people.freebsd.org/~mjg/lock_backoff_complete4.diff):
> > >
> > > Differences:
> > > - uint64_t usage was converted to u_int (also see r303584)
> > > - currently unused features (cap limit and return value) were removed
> > > - lock_delay args got packed into a dedicated structure
> >
> > lock_delay_enabled declaration seems to be stale?
> >
>
> Oops, thanks.
>
> > I would maybe just provide a "standard" lock_delay_init function that the
> > sysinit's use rather than duplicating the same exact code 3 times. I'm
> > not sure we really want to use different tunables for different lock types
> > anyway. (Alternatively we could even just have a single 'config' variable
> > that is a global. We can always revisit this in the future if we find that
> > we need that granularity, but it would remove an extra pointer indirection
> > if you just had a single 'lock_delay_config' that was exported as a global
> > for now and initialized in a single SYSINIT.)
> >
>
> The per-lock type config is partially an artifact of the real version of
> the patch which has different configs per state of the lock, see loops
> with rowner_loops in the current implementation of rw and sx locks and
> this is were it mattered. It was cut off from this patch for simplicity
> (90% of the benefit for 10% of the work).
>
> That said, fine tuned it does matter for "mere" spinning as well but
> here I put very low values on purpose.
>
> Putting them all in one config makes for a small compatibility issue,
> where debug.lock.delay_* sysctls would disappear later.
>
> So I would prefer to just keep this as I don't think it matters much.
Ok. This is also something we can change later if need to. It doesn't
affect the ABI, etc.
--
John Baldwin
More information about the freebsd-current
mailing list