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

2016-08-02 Thread Alfred Perlstein
Why is +struct lock_delay_config { +u_int initial; +u_int step; +u_int min; +u_int max; +}; missing comments for its members? Are they documented anywhere else? -Alfred On 7/31/16 5:41 AM, Mateusz Guzik wrote: On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov

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

2016-08-01 Thread John Baldwin
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

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

2016-08-01 Thread Mateusz Guzik
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: > >

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

2016-08-01 Thread John Baldwin
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: >

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

2016-08-01 Thread Mateusz Guzik
On Mon, Aug 01, 2016 at 09:38:09AM -0700, Maxim Sobolev wrote: > On Sun, Jul 31, 2016 at 1:36 PM, Mateusz Guzik wrote: > > > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > > Hi, > > > > > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there

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

2016-08-01 Thread Mateusz Guzik
On Mon, Aug 01, 2016 at 02:16:59PM +0300, Andriy Gapon wrote: > > Mateusz, > > just out of curiosity, have you tried to explore alternative spinlock > implementations like a ticket lock? It would be interesting to see if > there are any improvements to be gained there. > The patch is the

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

2016-08-01 Thread Maxim Sobolev
On Sun, Jul 31, 2016 at 1:36 PM, Mateusz Guzik wrote: > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > Hi, > > > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > > any performance degredations on lower count CPUs? > > > > I did not

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

2016-08-01 Thread Slawa Olhovchenkov
On Mon, Aug 01, 2016 at 02:16:59PM +0300, Andriy Gapon wrote: > > Mateusz, > > just out of curiosity, have you tried to explore alternative spinlock > implementations like a ticket lock? It would be interesting to see if > there are any improvements to be gained there. Effective ticket lock

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

2016-08-01 Thread Andriy Gapon
Mateusz, just out of curiosity, have you tried to explore alternative spinlock implementations like a ticket lock? It would be interesting to see if there are any improvements to be gained there. -- Andriy Gapon ___ freebsd-current@freebsd.org

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

2016-08-01 Thread Konstantin Belousov
On Sun, Jul 31, 2016 at 10:36:12PM +0200, Mateusz Guzik wrote: > On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > > Also, yeah, the MOD operator in each loop could get spendy on older > > CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to > > achieve much the same

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

2016-07-31 Thread K. Macy
On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd wrote: > Hi, > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > any performance degredations on lower count CPUs? The adaptive spinning path will never run on a uniprocessor. Except for potential

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

2016-07-31 Thread Mateusz Guzik
On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > Hi, > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > any performance degredations on lower count CPUs? > I did not test on machines which physically that few cpus, but I did test the impact on

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

2016-07-31 Thread Adrian Chadd
Hi, Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are any performance degredations on lower count CPUs? Also, yeah, the MOD operator in each loop could get spendy on older CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to achieve much the same autotuning with

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

2016-07-31 Thread Mateusz Guzik
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

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

2016-07-31 Thread Konstantin Belousov
On Sun, Jul 31, 2016 at 11:57:06AM +0200, Mateusz Guzik wrote: > The patch can be found inline below and also here: > https://people.freebsd.org/~mjg/lock_backoff_complete.diff > > The previous version of the patch was posted here: >

[PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Mateusz Guzik
The patch can be found inline below and also here: https://people.freebsd.org/~mjg/lock_backoff_complete.diff The previous version of the patch was posted here: https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062320.html This time around instead of a total hack I have something of