Messages in this thread | | | Date | Wed, 31 Mar 2004 13:28:06 -0500 | From | Ric Wheeler <> | Subject | Re: [PATCH] barrier patch set |
| |
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/
| |