Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Dec 2007 09:32:18 -0500
From:      Ken Smith <kensmith@cse.Buffalo.EDU>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Message-ID:  <1196778738.12497.18.camel@bauer.cse.buffalo.edu>
In-Reply-To: <fj3jc6$ba2$1@ger.gmane.org>
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> <fj3jc6$ba2$1@ger.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-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--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1196778738.12497.18.camel>