From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755531Ab1KUOqg (ORCPT ); Mon, 21 Nov 2011 09:46:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47138 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752387Ab1KUOqe (ORCPT ); Mon, 21 Nov 2011 09:46:34 -0500 From: Jeff Moyer To: Wu Fengguang Cc: Andrew Morton , Linux Memory Management List , , Li Shaohua , Clemens Ladisch , Jens Axboe , Rik van Riel , LKML , Andi Kleen Subject: Re: [PATCH 1/8] block: limit default readahead size for small devices References: <20111121091819.394895091@intel.com> <20111121093846.121502745@intel.com> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Mon, 21 Nov 2011 09:46:10 -0500 In-Reply-To: <20111121093846.121502745@intel.com> (Wu Fengguang's message of "Mon, 21 Nov 2011 17:18:20 +0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wu Fengguang writes: > Linus reports a _really_ small & slow (505kB, 15kB/s) USB device, > on which blkid runs unpleasantly slow. He manages to optimize the blkid > reads down to 1kB+16kB, but still kernel read-ahead turns it into 48kB. > > lseek 0, read 1024 => readahead 4 pages (start of file) > lseek 1536, read 16384 => readahead 8 pages (page contiguous) > > The readahead heuristics involved here are reasonable ones in general. > So it's good to fix blkid with fadvise(RANDOM), as Linus already did. > > For the kernel part, Linus suggests: > So maybe we could be less aggressive about read-ahead when the size of > the device is small? Turning a 16kB read into a 64kB one is a big deal, > when it's about 15% of the whole device! > > This looks reasonable: smaller device tend to be slower (USB sticks as > well as micro/mobile/old hard disks). > > Given that the non-rotational attribute is not always reported, we can > take disk size as a max readahead size hint. This patch uses a formula > that generates the following concrete limits: > > disk size readahead size > (scale by 4) (scale by 2) > 1M 8k > 4M 16k > 16M 32k > 64M 64k > 256M 128k > --------------------------- (*) > 1G 256k > 4G 512k > 16G 1024k > 64G 2048k > 256G 4096k > > (*) Since the default readahead size is 128k, this limit only takes > effect for devices whose size is less than 256M. Scaling readahead by the size of the device may make sense up to a point. But really, that shouldn't be the only factor considered. Just because you have a big disk, it doesn't mean it's fast, and it sure doesn't mean that you should waste memory with readahead data that may not be used before it's evicted (whether due to readahead on data that isn't needed or thrashing of the page cache). So, I think reducing the readahead size for smaller devices is fine. I'm not a big fan of going the other way. Cheers, Jeff