Re: svn commit: r332285 - head/sys/kern

2018-04-08 Thread Mateusz Guzik
On Sun, Apr 8, 2018 at 9:06 PM, Steven Hartland <
steven.hartl...@multiplay.co.uk> wrote:

> Worth making the sysctls so they can be tuned the the HW / use case?
>

they already are, see:
sysctl debug.mtx debug.mtx_spin debug.rwlock debug.sx

-- 
Mateusz Guzik 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r332285 - head/sys/kern

2018-04-08 Thread Steven Hartland

Worth making the sysctls so they can be tuned the the HW / use case?

On 08/04/2018 17:34, Mateusz Guzik wrote:

Author: mjg
Date: Sun Apr  8 16:34:10 2018
New Revision: 332285
URL: https://svnweb.freebsd.org/changeset/base/332285

Log:
   locks: tweak backoff a little bit
   
   Previous limits were chosen when locking primitives had spurious lock

   accesses.
   
   Flipping the starting point to 1 (or rather 2 as the first call shifts it)

   provides a modest win when mild contention is seen while not hurting worse
   cases. Tested on a bunch of one, two and four socket old and new systems
   (Westmere, Skylake, Threadreaper and others) by doing concurrent page faults,
   buildkernel/buildworld and other stuff (although not all systems got all the
   tests).
   
   Another thing is the upper limit. It is semi-arbitrarily chosen as it was

   getting out of hand for slightly less small systems (e.g. a 128-thread one).
   
   Note that backoff is fundamentally a speculative bandaid and this change just

   makes it fit a little bit better. It remains completely oblivious to the
   hardware topology or the contention pattern. This is being experimented with.

Modified:
   head/sys/kern/subr_lock.c

Modified: head/sys/kern/subr_lock.c
==
--- head/sys/kern/subr_lock.c   Sun Apr  8 16:29:24 2018(r332284)
+++ head/sys/kern/subr_lock.c   Sun Apr  8 16:34:10 2018(r332285)
@@ -156,8 +156,10 @@ void
  lock_delay_default_init(struct lock_delay_config *lc)
  {
  
-	lc->base = lock_roundup_2(mp_ncpus) / 4;

-   lc->max = lc->base * 1024;
+   lc->base = 1;
+   lc->max = lock_roundup_2(mp_ncpus) * 256;
+   if (lc->max > 32678)
+   lc->max = 32678;
  }
  
  #ifdef DDB




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r332285 - head/sys/kern

2018-04-08 Thread Mateusz Guzik
Author: mjg
Date: Sun Apr  8 16:34:10 2018
New Revision: 332285
URL: https://svnweb.freebsd.org/changeset/base/332285

Log:
  locks: tweak backoff a little bit
  
  Previous limits were chosen when locking primitives had spurious lock
  accesses.
  
  Flipping the starting point to 1 (or rather 2 as the first call shifts it)
  provides a modest win when mild contention is seen while not hurting worse
  cases. Tested on a bunch of one, two and four socket old and new systems
  (Westmere, Skylake, Threadreaper and others) by doing concurrent page faults,
  buildkernel/buildworld and other stuff (although not all systems got all the
  tests).
  
  Another thing is the upper limit. It is semi-arbitrarily chosen as it was
  getting out of hand for slightly less small systems (e.g. a 128-thread one).
  
  Note that backoff is fundamentally a speculative bandaid and this change just
  makes it fit a little bit better. It remains completely oblivious to the
  hardware topology or the contention pattern. This is being experimented with.

Modified:
  head/sys/kern/subr_lock.c

Modified: head/sys/kern/subr_lock.c
==
--- head/sys/kern/subr_lock.c   Sun Apr  8 16:29:24 2018(r332284)
+++ head/sys/kern/subr_lock.c   Sun Apr  8 16:34:10 2018(r332285)
@@ -156,8 +156,10 @@ void
 lock_delay_default_init(struct lock_delay_config *lc)
 {
 
-   lc->base = lock_roundup_2(mp_ncpus) / 4;
-   lc->max = lc->base * 1024;
+   lc->base = 1;
+   lc->max = lock_roundup_2(mp_ncpus) * 256;
+   if (lc->max > 32678)
+   lc->max = 32678;
 }
 
 #ifdef DDB
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"