Date: Sat, 5 Feb 2005 15:28:43 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: performance@FreeBSD.org Subject: Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x Message-ID: <Pine.NEB.3.96L.1050205152437.55669B-100000@fledge.watson.org> In-Reply-To: <20050204225308.GJ163@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Feb 2005, Jeremie Le Hen wrote: > > I have the numbers below, but here are the conclusions: on this hardware, > > using a single ATA disk, there was no real measurable performance > > difference between UP/SMP, and 4.x/6.x -- 6.x came out slightly ahead on > > t/s, but not hugely so. I take this to mean that the hardware was > > basically I/O bound on file system meta-data operations. > > Thank you for your tests Robert. I don't want to consume your precious > time needlessly, but I would like to compare these results with 5.x > performances. There are already many improvements in CURRENT that will > never be MFC'ed to RELENG_5 and this will show us if we can expect > RELENG_5 to be someday as effective as RELENG_4 and CURRENT are. I'll attempt to get a 5.x kernel on the box today and see how it looks. While it's true there is work in 6.x that won't be merged to 5.x, a lot of the interesting work will be. In particular, we'd like to work hard to not let 5.x diverge substantially from 6.x, where it's possible. This means you'll see a lot more getting merged to 5.x after testing and exercise in 6.x. For example, pretty much all network performance work is getting merged to 5.x within a couple of months from 6.x; likewise, I know that Jeff is very interested in getting the MPSAFE VFS into 5.x in the medium term (as an option, not the default), and Soren has every intent of merging the new atamkIII work once it's settled (presumably a bit after 5.4). Everyone agrees the gap between 5.x and 4.x was allowed to get much too large, so between more frequent cuts from -CURRENT to -STABLE, and keeping -CURRENT and -STABLE more in sync, we hope to prevent this from happening in the future. The plan, of course, is to do this without negatively impacting the performance and stability of the -STABLE branch, so it will be a careful balancing act. Thus far, it seems to be working out well: the performance and stability of RELENG_5 has increased since the 5.3 release, despite relatively agressive merging. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050205152437.55669B-100000>