From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754990AbZFFOgv (ORCPT ); Sat, 6 Jun 2009 10:36:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753787AbZFFOgp (ORCPT ); Sat, 6 Jun 2009 10:36:45 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:60764 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753455AbZFFOgn (ORCPT ); Sat, 6 Jun 2009 10:36:43 -0400 From: KOSAKI Motohiro To: "Alan D. Brunelle" Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev Cc: kosaki.motohiro@jp.fujitsu.com, Hisashi Hifumi , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Wu Fengguang In-Reply-To: <4A2936A7.9070309@gmail.com> References: <6.0.0.20.2.20090601095926.06ee98d8@172.19.0.2> <4A2936A7.9070309@gmail.com> Message-Id: <20090606233056.7B9F.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.07 [ja] Date: Sat, 6 Jun 2009 23:36:41 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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.