Date: Sat, 24 Nov 2007 20:49:13 +0100 From: Max Laier <max@love2party.net> To: Kris Kennaway <kris@freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: Switch pfil(9) to rmlocks Message-ID: <200711242049.19466.max@love2party.net> In-Reply-To: <47487946.2010202@FreeBSD.org> References: <200711231232.04447.max@love2party.net> <200711242006.04753.max@love2party.net> <47487946.2010202@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2081520.LFnXRmukbg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 24 November 2007, Kris Kennaway wrote: > Max Laier wrote: > > On Friday 23 November 2007, Robert Watson wrote: > >> On Fri, 23 Nov 2007, Max Laier wrote: > >>> attached is a diff to switch the pfil(9) subsystem to rmlocks, > >>> which are more suited for the task. I'd like some exposure before > >>> doing the switch, but I don't expect any fallout. This email is > >>> going through the patched pfil already - twice. > >> > >> Max, > >> > >> Have you done performance measurements that show rmlocks to be a win > >> in this scenario? I did some patchs for UNIX domain sockets to > >> replace the rwlock there but it appeared not to have a measurable > >> impact on SQL benchmarks, presumbaly because the read/write blend > >> wasn't right and/or that wasnt a significant source of overhead in > >> the benchmark. I'd anticipate a much more measurable improvement > >> for pfil, but would be interested in learning how much is seen? > > > > I had to roll an artificial benchmark in order to see a significant > > change (attached - it's a hack!). > > > > Using 3 threads on a 4 CPU machine I get the following results: > > null hook: ~13% +/- 2 > > mtx hook: up to 40% [*] > > rw hook: ~5% +/- 1 > > rm hook: ~35% +/- 5 > > > > [*] The mtx hook is inconclusive as my measurements vary a lot. If > > one thread gets lucky and keeps running the overall time obviously > > goes down by a magnitude. It seems however, that rmlocks greatly > > increase the chance of that happening - not sure if that's a good > > thing, though. If all threads receive approximately equal runtime > > (which is almost always the case for rwlocks) the difference is > > somewhere around 10%. > > Is that something we can try to arrange to happen for improved > performance in more general situations? I don't think so. It's a scheduling problem, but one you can't (easily)=20 predict. The gain comes from reduced congestion after one thread is=20 done, which doesn't happen in real world situations. You are never done. = =20 The only way to reduce congestion is to shrink critical sections and to=20 use read locks whenever possible. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2081520.LFnXRmukbg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHSIA/XyyEoT62BG0RAuhJAJwJEUJuDUDj9FZqYj5KQZabFl2u3ACeIsCr mQX5c/SlFbfwPTleO7iebY0= =BDPT -----END PGP SIGNATURE----- --nextPart2081520.LFnXRmukbg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711242049.19466.max>