Date: Sun, 31 Jul 2016 14:57:58 -0700 From: "K. Macy" <kmacy@freebsd.org> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Mateusz Guzik <mjguzik@gmail.com>, John Baldwin <jhb@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, Konstantin Belousov <kib@freebsd.org> Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <CAHM0Q_OFLEM%2BPJt1Cq0OXAAKdZ0m5kFwP=H9XT=tTQguVEmsxw@mail.gmail.com> In-Reply-To: <CAJ-VmokxFFe4iAuMKEZuCjua4YUHx=PiXJKSBibsDKxWOrm7uA@mail.gmail.com> References: <20160731095706.GB9408@dft-labs.eu> <CAJ-VmokxFFe4iAuMKEZuCjua4YUHx=PiXJKSBibsDKxWOrm7uA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd <adrian.chadd@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHM0Q_OFLEM%2BPJt1Cq0OXAAKdZ0m5kFwP=H9XT=tTQguVEmsxw>