Re: [PATCH] barrier patch set

From: Ric Wheeler (ric_at_emc.com)
Date: 03/31/04

  • Next message: Jamie Lokier: "Re: [2.6.2] Badness in futex_wait revisited" 
    Date:	Wed, 31 Mar 2004 13:28:06 -0500
To: Chris Mason <mason@suse.com>

    As one of the large users of the Jens and Chris's barrier support in
    2.4, I am very motivated to help validate and benchmark the new version.

    Stephen, if you have a specific mysql workload or usage case, I can try
    to through that into the mix. We do a lot of Sleepycat DB testing,
    would results from that help?

    Ric

    Chris Mason wrote:

    >On Wed, 2004-03-31 at 09:03, Stephen C. Tweedie wrote:
    >
    >
    >>Hi,
    >>
    >>On Tue, 2004-03-30 at 23:13, Chris Mason wrote:
    >>
    >>
    >>
    >>>Most database benchmarks are done on scsi, and the blkdev_flush should
    >>>be a noop there. For IDE based database and mail server benchmarks, the
    >>>results won't be pretty.
    >>>
    >>>
    >>Yep. I'm really not too worried about big database benchmarks -- those
    >>are very much special cases, using rather specialised storage setup
    >>(SCSI or FC, striped over lots of small disks rather than fewer large
    >>ones.) I'm much more concerned about your average LAMP user's mysql
    >>database, and how to keep performance sane on that.
    >>
    >>
    >>
    >In some cases, it's going to be so much slower that it will look like
    >the old code wasn't writing the data at all. I don't think there's much
    >we can do about that.
    >
    >
    >
    >>>The reiserfs fsync code tries hard to only flush once, so if a commit is
    >>>done then blkdev_flush isn't called. We might have to do a few other
    >>>tricks to queue up multiple synchronous ios and only flush once.
    >>>
    >>>
    >>Batching is really helpful when you've got lots of threads that can be
    >>coalesced, yes. ext3 does that for things like mail servers. I'm not
    >>sure whether the same tricks will apply to the various databases out
    >>there, though.
    >>
    >>
    >
    >We can do better in general when there's more then one process doing an
    >fsync. reiserfs and ext3 both try to be smart about batching log
    >commits, but I think we could do more to streamline the data writes.
    >
    >I'm playing with a few ideas, I'll post more when I've got real code to
    >back things up.
    >
    >If there's only one process doing fsyncs, there's not much the kernel
    >can do except provide an aio fsync call.
    >
    >-chris
    >
    >
    >
    >
    >-
    >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    >the body of a message to majordomo@vger.kernel.org
    >More majordomo info at http://vger.kernel.org/majordomo-info.html
    >Please read the FAQ at http://www.tux.org/lkml/
    >
    >
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jamie Lokier: "Re: [2.6.2] Badness in futex_wait revisited"