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

From: K. Macy <kmacy_at_freebsd.org>
Date: Sun, 31 Jul 2016 14:57:58 -0700
On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd <adrian.chadd_at_gmail.com> 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 i-cache displacement you're not going to actually see
any effect unless there is substantial contention. You'll need all
threads consistently contending for the same lock. A potential
workload to exercise this would be to run ncpu threads sending small
UDP packets on a driver with a legacy mutex protected IFQ interface.


> 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 pow2 operations instead of
> divide/mod?
>
>
> -a
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
Received on Sun Jul 31 2016 - 19:57:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:07 UTC