Re: [PATCH] barrier patch set

[Ric Wheeler <ric@emc.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/
>  
>