From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sonny Rao Subject: Re: ext3 writepages ? Date: Thu, 10 Feb 2005 15:25:34 -0500 Message-ID: <20050210202534.GA3392@kevlar.burdell.org> References: <1108060325.20053.1145.camel@dyn318077bld.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pbadari@us.ibm.com, Andreas Dilger , linux-fsdevel@vger.kernel.org Received: from dsl027-162-124.atl1.dsl.speakeasy.net ([216.27.162.124]:22174 "EHLO kevlar.burdell.org") by vger.kernel.org with ESMTP id S261883AbVBJUiu (ORCPT ); Thu, 10 Feb 2005 15:38:50 -0500 To: Bryan Henderson Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Feb 10, 2005 at 12:30:23PM -0800, Bryan Henderson wrote: > >Its possible that by doing larger > >IOs we save CPU and use that CPU to push more data ? > > This is absolutely right; my mistake -- the relevant number is CPU seconds > per megabyte moved, not CPU seconds per elapsed second. > But I don't think we're close enough to 100% CPU utilization that this > explains much. > > In fact, the curious thing here is that neither the disk nor the CPU seems > to be a bottleneck in the slow case. Maybe there's some serialization I'm > not seeing that makes less parallelism between I/O and execution. Is this > a single thread doing writes and syncs to a single file? >>From what I've seen, without writepages, the application thread itself tends to do the writing by falling into balance_dirty_pages() during it's write call, while in the writepages case, a pdflush thread seems to do more of the writeback. This also depends somewhat on processor speed (and number) and amount of RAM. To try and isolate this more, I've limited RAM (1GB) and number of CPUs (1) on my testing setup. So yes, there could be better parallelism in the writepages case, but again this behavior could be a symptom and not a cause, but I'm not sure how to figure that out, any suggestions ? Sonny