From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: background on the ext3 batching performance issue Date: Thu, 28 Feb 2008 12:02:44 -0500 Message-ID: <200802281202.45361.chris.mason@oracle.com> References: <47C6A46D.8020700@emc.com> <200802281041.01411.jbacik@redhat.com> <47C6B2A5.4030609@emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Josef Bacik , "Theodore Ts'o" , adilger@sun.com, David Chinner , jack@ucw.cz, "Feld, Andy" , linux-fsdevel@vger.kernel.org To: Ric Wheeler Return-path: Received: from rgminet01.oracle.com ([148.87.113.118]:15619 "EHLO rgminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757897AbYB1RFr (ORCPT ); Thu, 28 Feb 2008 12:05:47 -0500 In-Reply-To: <47C6B2A5.4030609@emc.com> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thursday 28 February 2008, Ric Wheeler wrote: [ fsync batching can be slow ] > One more thought - what we really want here is to have a sense of the > latency of the device. In the S-ATA disk case, this optimization works > well for batching since we "spend" an extra 4ms worst case in the chance > of combining multiple, slow 18ms operations. > > With the clariion box we tested, the optimization fails badly since the > cost is only 1.3 ms so we optimize by waiting 3-4 times longer than it > would take to do the operation immediately. > > This problem has also seemed to me to be the same problem that IO > schedulers do with plugging - we want to dynamically figure out when to > plug and unplug here without hard coding in device specific tunings. > > If we bypass the snippet for multi-threaded writers, we would probably > slow down this workload on normal S-ATA/ATA drives (or even higher > performance non-RAID disks). It probably makes sense to keep track of the average number of writers we are able to gather into a transcation. There are lots of similar workloads where we have a pool of procs doing fsyncs and the size of the transaction or the number of times we joined a running transaction will be fairly constant. -chris