From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755808Ab1KUJ4p (ORCPT ); Mon, 21 Nov 2011 04:56:45 -0500 Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net ([173.166.109.252]:39108 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754745Ab1KUJ4o (ORCPT ); Mon, 21 Nov 2011 04:56:44 -0500 Date: Mon, 21 Nov 2011 04:56:38 -0500 From: Christoph Hellwig To: Wu Fengguang Cc: Andrew Morton , Linux Memory Management List , linux-fsdevel@vger.kernel.org, LKML , Andi Kleen Subject: Re: [PATCH 0/8] readahead stats/tracing, backwards prefetching and more Message-ID: <20111121095638.GA5084@infradead.org> References: <20111121091819.394895091@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111121091819.394895091@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 21, 2011 at 05:18:19PM +0800, Wu Fengguang wrote: > Andrew, > > I'm getting around to pick up the readahead works again :-) > > This first series is mainly to add some debug facilities, to support the long > missed backwards prefetching capability, and some old patches that somehow get > delayed (shame me). > > The next step would be to better handle the readahead thrashing situations. > That would require rewriting part of the algorithms, this is why I'd like to > keep the backwards prefetching simple and stupid for now. > > When (almost) free of readahead thrashing, we'll be in a good position to lift > the default readahead size. Which I suspect would be the single most efficient > way to improve performance for the large volumes of casually maintained Linux > file servers. Btw, if you work actively in that area I have a todo list item I was planning to look into sooner or later: instead of embedding the ra state into the struct file allocate it dynamically. That way files that either don't use the pagecache, or aren't read from won't need have to pay the price for increasing struct file size, and if we have to we could enlarge it more easily. Besides removing f_version in the common struct file and also allocting f_owner separately that seem to be the easiest ways to get struct file size down.