lkml.org 
[lkml]   [2004]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.156 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site