From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: [JBD] change batching logic to improve O_SYNC performance Date: Thu, 15 Dec 2005 09:22:23 -0500 Message-ID: <43A17C1F.6070906@emc.com> References: <20051215145951.GB2444@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: akpm@osdl.org, sct@redhat.com, linux-fsdevel@vger.kernel.org, Jens Axboe , Chris Mason Return-path: Received: from mexforward.lss.emc.com ([168.159.213.200]:4958 "EHLO mexforward.lss.emc.com") by vger.kernel.org with ESMTP id S1750827AbVLOR0G (ORCPT ); Thu, 15 Dec 2005 12:26:06 -0500 To: Benjamin LaHaise In-Reply-To: <20051215145951.GB2444@kvack.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Benjamin LaHaise wrote: > Hello folks, > > When writing files out using O_SYNC, jbd's 1 jiffy delay results in a > significant drop in throughput as the disk sits idle. The patch below > results in a 4-5x performance improvement (from 6.5MB/s to ~24-30MB/s on > my IDE test box) when writing out files using O_SYNC. Instead of always > delaying for 1 jiffy when trying to batch, merely do a yield() to allow > other processes to execute and potentially batch requests. Additionally, > limit the delay to an absolute max of 1/50th of a second. > > -ben > I was playing with similar code in reiserfs last year, trying to tune for fsync() performance. The challenge is that when the rate of fsync() arrivals is low, you don't want to introduce extra latency for these "lonely" requests while you wait for a request to combine which is not going to come any time soon. On the other hand, if the rate of fsync() requests is high enough, you gain a huge performance win by combining multiple fsync()'s into one transaction. This feels a bit like the IO combining logic in the io scheduler layer. It would seem to be begging for some dynamic logic based on the arrival rate for both the fsync & synchronous write combining... ric