From owner-freebsd-stable@FreeBSD.ORG Tue Dec 4 14:32:25 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D899916A41B for ; Tue, 4 Dec 2007 14:32:25 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0ED13C447 for ; Tue, 4 Dec 2007 14:32:25 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id lB4EWITm069796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 09:32:19 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Ivan Voras In-Reply-To: References: <20071201213732.GA16638@cannabis.dataforce.net> <1497741406.20071201230441@rulez.sk> <20071202174540.GA29572@cannabis.dataforce.net> <200712020844.49718.linimon@FreeBSD.org> <4753C9E4.1060200@chistydom.ru> <20071203114037.G79674@fledge.watson.org> <47542372.3040303@chistydom.ru> <20071203163353.J79674@fledge.watson.org> <47551C1C.3000903@chistydom.ru> <47553170.90409@bulinfo.net> <20071204121329.N87930@fledge.watson.org> <47554773.2080806@bulinfo.net> <20071204123116.G87930@fledge.watson.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Yb7Bhyra5CNctt9WVLFi" Organization: U. Buffalo CSE Department Date: Tue, 04 Dec 2007 09:32:18 -0500 Message-Id: <1196778738.12497.18.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 14:32:25 -0000 --=-Yb7Bhyra5CNctt9WVLFi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-12-04 at 14:11 +0100, Ivan Voras wrote: > Robert Watson wrote: >=20 > > Changing > > locking primitives, as I mentioned in an earlier post, is a risky thing= : > > after all, it intentionally changes the timing for critical kernel data > > structures in the file system code. I've given Stephan, the author of > > the patch, a ping to ask him about this, but late in a release cycle, > > conservativism is the watch-word. >=20 > Agreed, but it would be a shame to miss on the momentum 7.0 has acquired > for performance. Web servers are so common that there's a huge chance > one of the first thing people will do with 7.0 would be some kind of > web-benchmarks, especially after this thread on stable@. Though (as I > read the thread) the patch won't bring FreeBSD in line with Linux, it > will help it not to be so slow it's silly. >=20 > Re: timings: Would looking at past instances give insight into future? I > don't remember the time accurately, but in the past, when VFS was > translated to MPSAFE and the locking reengineered, were there such proble= ms? >=20 > Maybe Peter Holm can run a week or so of constant stress testing > (24-hours-a-day) with the patch to verify it at least in short term? >=20 I need to agree with Robert on this one. At some point you need to stop fiddling with nits, cut the release, and then fiddle with the nits in preparation for the next release. As we get closer to the point we think we can actually do the release RE needs to weigh the benefits of commit requests versus the risks. One of the biggest factors in our evaluation of the benefits is whether it's addressing an issue that completely blocks functionality (due to the bugs the system panics or otherwise does not do something it should) or if it "merely" improves on something. The latter we really need to consider extremely carefully because it's *possible* that adjustment would lead to the introduction of new bugs of the "blocks functionality" form. And this thread demonstrates to some degree exactly why a week of Peter Holm's stress testing doesn't leave us with the warm fuzzy feeling that an adjustment is perfect. It shows it's OK for his synthetic workload. But synthetic workloads of various forms showed improvements in throughput with 7.0 versus 6.3 while other workloads (e.g. the one that started off this thread...) don't. Whether 7.0 helps with peoples' workloads or not there is one thing in common throughout this thread and that's nobody here has been saying the system fails completely (note I said *this* *thread*... :-). RE values that over people getting improved performance for specific workloads at *this* phase of a release cycle. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-Yb7Bhyra5CNctt9WVLFi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHVWTy/G14VSmup/YRAi8zAJ9RU6XvMqx/VBhbA8Nv3EVzw2DDegCeLVmV MjzLOaX6DpaEmsva40Z7+z4= =5mZd -----END PGP SIGNATURE----- --=-Yb7Bhyra5CNctt9WVLFi--