From mboxrd@z Thu Jan 1 00:00:00 1970 From: KOSAKI Motohiro Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev Date: Sat, 6 Jun 2009 23:36:41 +0900 (JST) Message-ID: <20090606233056.7B9F.A69D9226@jp.fujitsu.com> References: <6.0.0.20.2.20090601095926.06ee98d8@172.19.0.2> <4A2936A7.9070309@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: kosaki.motohiro@jp.fujitsu.com, Hisashi Hifumi , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Wu Fengguang To: "Alan D. Brunelle" Return-path: In-Reply-To: <4A2936A7.9070309@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org sorry for late responce. I wonder why I and Wu don't contain Cc list in this thread. > Hisashi Hifumi wrote: > > At 09:36 09/06/01, Andrew Morton wrote: > >> On Fri, 29 May 2009 14:35:55 +0900 Hisashi Hifumi > >> wrote: > >> > >>> I added blk_run_backing_dev on page_cache_async_readahead > >>> so readahead I/O is unpluged to improve throughput on > >>> especially RAID environment. > >> I skipped the last version of this because KOSAKI Motohiro > >> said "Please attach blktrace analysis ;)". > >> > >> I'm not sure why he asked for that, but he's a smart chap and > >> presumably had his reasons. > >> > >> If you think that such an analysis is unneeded, or isn't worth the time > >> to generate then please tell us that. But please don't just ignore the > >> request! > > > > Hi Andrew. > > > > Sorry for this. > > > > I did not ignore KOSAKI Motohiro's request. > > I've got blktrace output for both with and without the patch, > > but I just did not clarify the reason for throuput improvement > > from this result. > > > > I do not notice any difference except around unplug behavior by dd. > > Comments? > > Pardon my ignorance on the global issues concerning the patch, but > specifically looking at the traces generated by blktrace leads one to > also note that the patched version may generate inefficiencies in other > places in the kernel by reducing the merging going on. In the unpatched > version it looks like (generally) that two incoming bio's are able to be > merged to generate a single I/O request. In the patched version - > because of the quicker unplug(?) - no such merging is going on. This > leads to more work lower in the stack (twice as many I/O operations > being managed), perhaps increased interrupts & handling &c. [This may be > acceptable if the goal is to decrease latencies on a per-bio basis...] > > Do you have a place where the raw blktrace data can be retrieved for > more in-depth analysis? I think your comment is really adequate. In another thread, Wu Fengguang pointed out the same issue. I and Wu also wait his analysis. Thanks.