Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 02/05/05

  • Next message: Robert Watson: "Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x" 
    Date: Sat, 5 Feb 2005 15:28:43 +0000 (GMT)
To: Jeremie Le Hen <jeremie@le-hen.org>

    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

    _______________________________________________
    freebsd-performance@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"

  • Next message: Robert Watson: "Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x"