From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 20:21:10 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FC38106568B; Wed, 1 Oct 2008 20:21:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:3fb::211]) by mx1.freebsd.org (Postfix) with ESMTP id B5AC28FC08; Wed, 1 Oct 2008 20:21:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DB3FA1CD1C; Wed, 1 Oct 2008 22:21:08 +0200 (CEST) Date: Wed, 1 Oct 2008 22:21:08 +0200 From: Ed Schouten To: Poul-Henning Kamp Message-ID: <20081001202108.GO16837@hoeg.nl> References: <69186.1222890415@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ccJhwVfaC+fHwTsl" Content-Disposition: inline In-Reply-To: <69186.1222890415@critter.freebsd.dk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD FS , Mark van Cuijk , Jille Timmermans , FreeBSD Arch Subject: Re: Expanding vops in vop_vectors during startup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 20:21:10 -0000 --ccJhwVfaC+fHwTsl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Poul-Henning, * Poul-Henning Kamp wrote: > In message <20081001190728.GL16837@hoeg.nl>, Ed Schouten writes: >=20 > >The reason I'm sending this message, is because based on discussions I > >had with several people on IRC we've basically got two different > >opinions on this patch: > > > >- One group of people liked the idea of the patch. Some people even said > > the patch looks good enough to be committed. > > > >- Another group of people also liked the idea, but thought it would make > > no sense to commit it, because it's not like it's a bottleneck right > > now. It should only be committed if an increase in performance is > > notable. > > > >I did some tests with the patch set, by running tens of millions of > >fstat(), fchown(), etc. calls to see how performance was affected. It > >turns out on a kernel without any debugging options enabled, the > >performance gain is only 1-2%, which sounds pretty valid to me. >=20 >=20 > My resistance to this patch is not quite what you describe above: >=20 > By factoring the vop vectors out, you remove the ability to let > default vectors pick up new functionality later. Could you give me an example of such functionality? You mean extending a vop_vector? That shouldn't be a problem, right? If such functionality really seems to be in conflict with this modification, it's not like we're carving things in stone here. > I will admit that I have no knowledge of this level of generality, > dating back from Heidemans Phd. dissertation, being used for anything > sensible. >=20 > Furthermore, if I am not mistaken, your patch increases the kernel > size. Even though I admit I don't have that many file system types compiled into my kernel, binary size is 2203 bytes smaller with my patch applied. If you have a whole bunch of filesystems compiled into your kernel, these numbers might be a little different. We now need an extra SYSINIT per struct vop_vector. > Absent a plausible performance improvement, I don't see any point > of your change. >=20 > And that brings me to your "1-2%" measurement quoted in IRC and > above. >=20 > I have earlier ranted about the difference between benchmarking=20 > and random number generators, and you may have joined the project > after the latest of these. >=20 > Please search the mail-archives for that topic, and then use > the handy ministat(1) program, to see if you have actually=20 > show any net speed benefit. >=20 > Once and if you cross that threshold, I am going to raise my next > objection: >=20 > Benchmarking "tens of millions of fstat(), fchown(), etc. calls" > and showing a 1-2% difference is patently bogus, and certainly > no reason for the change you propose. ministat(1) also mentions a 2% improvement with 95.0% confidence. Quite a nifty tool. Thanks for pointing me to it. About the benchmarks: the reason why I decided to test these things, was because I didn't want to measure disk I/O performance. I just wanted to see how performance was different with respect to VOP_*() calls. This means most of the cases I tested scenario's when data would already be available from cache or on pseudo-filesystems, where real disk I/O would not occur. But as I said: I am not going to commit it. End of discussion. --=20 Ed Schouten WWW: http://80386.nl/ --ccJhwVfaC+fHwTsl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjj27QACgkQ52SDGA2eCwWqPgCfUKBUYLojYXtQdUm3/h71Z/gf lzMAnjGwVodxtPVsvJ700h73MPZ7Xylk =/2f/ -----END PGP SIGNATURE----- --ccJhwVfaC+fHwTsl--