Re: [PATCH] randomized delay in locking primitives, take 2

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?

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.)

I think the idea is fine.  I'm less worried about the overhead of the
divide as you are only doing it when you are contesting (so you are already
sort of hosed anyway).  Long delays in checking the lock cookie can be
bad (see my local APIC snafu which only polled once per microsecond).  I
don't really think a divide is going to be that long?

-- 
John Baldwin