From owner-freebsd-net@FreeBSD.ORG Sat Nov 24 19:48:35 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425C916A41A; Sat, 24 Nov 2007 19:48:35 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id BFDF513C45B; Sat, 24 Nov 2007 19:48:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-008-048.pools.arcor-ip.net [88.66.8.48]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1Iw0zM48hV-0000wh; Sat, 24 Nov 2007 20:48:29 +0100 From: Max Laier Organization: FreeBSD To: Kris Kennaway Date: Sat, 24 Nov 2007 20:49:13 +0100 User-Agent: KMail/1.9.7 References: <200711231232.04447.max@love2party.net> <200711242006.04753.max@love2party.net> <47487946.2010202@FreeBSD.org> In-Reply-To: <47487946.2010202@FreeBSD.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2081520.LFnXRmukbg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711242049.19466.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18wO8VxTpO522mMEmtJdLgjl6ogLdxgc/88/6D T0am9H57nr8jAN+iQ/41d7LW2NKn/YtY72QghKIuCs6hr5kSun gxwHdx6zBkcZ8yuiAKhlo8A2qrWHesQSzuDf/8Bwus= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Switch pfil(9) to rmlocks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 19:48:35 -0000 --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--