Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755277AbZFEPXd (ORCPT ); Fri, 5 Jun 2009 11:23:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751814AbZFEPXY (ORCPT ); Fri, 5 Jun 2009 11:23:24 -0400 Received: from qw-out-2122.google.com ([74.125.92.26]:45279 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751683AbZFEPXX (ORCPT ); Fri, 5 Jun 2009 11:23:23 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kHxhPDFxAvF0QvhZHb4lyriSLLfk4wCcT3yPxhIxXwdEd635QKrgFtZNQLbC1HK28e NB2xsYctnm7r2uzdg1xXpMVFGwkoQaZnqzH5YzsYRWEk9wZsVERFoWBlT5mlb55X3Vuu /qzJO2XgxHu0gaZ1/HpkjjPqDk+/9NSDaHVLE= Message-ID: <4A2936A7.9070309@gmail.com> Date: Fri, 05 Jun 2009 11:15:51 -0400 From: "Alan D. Brunelle" Reply-To: "Alan D. Brunelle" User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Hisashi Hifumi CC: Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev References: <6.0.0.20.2.20090529142527.071669e0@172.19.0.2> <20090531173604.8cbad7f2.akpm@linux-foundation.org> <6.0.0.20.2.20090601095926.06ee98d8@172.19.0.2> In-Reply-To: <6.0.0.20.2.20090601095926.06ee98d8@172.19.0.2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2137 Lines: 52 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? Regards, Alan D. Brunelle Hewlett-Packard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/