Date: Sun, 31 Jul 2016 22:36:12 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: 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: <20160731203612.GH9408@dft-labs.eu> 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 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 microbenchmark with 2 and 4 threads on the 80-way machine. There was no difference. For this iteration of the patch, given limited time I tried to be very conservative as to not intoduce additional latency. In fact I would argue the patch is undertuned (as in, it can do better in certain workloads). That said, I think it is safe to use. > 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? > The % operation acts a randomizer. It is optional and I'm happy to ifdef it based on the architecture. It does seem to be useful at least on amd64. As a side note, exponential backoff is not used to keep things smaller (see above). It is definitely subject to change later. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160731203612.GH9408>