Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964916AbWEBQfw (ORCPT ); Tue, 2 May 2006 12:35:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964920AbWEBQfw (ORCPT ); Tue, 2 May 2006 12:35:52 -0400 Received: from ns1.suse.de ([195.135.220.2]:38588 "EHLO mx1.suse.de") by vger.kernel.org with ESMTP id S964916AbWEBQfv (ORCPT ); Tue, 2 May 2006 12:35:51 -0400 To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, Andrew Morton , Jens Axboe , Nick Piggin , Badari Pulavarty , wfg@mail.ustc.edu.cn Subject: Re: [RFC] kernel facilities for cache prefetching References: <346556235.24875@ustc.edu.cn> From: Andi Kleen Date: 02 May 2006 18:35:50 +0200 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 998 Lines: 18 Linus Torvalds writes: > > The downsides basically boil down to the fact that it's not as clearly > just one single point. You can't just look at the request queue and see > what physical requests go out. The other problem is that readpages has no idea about the layout of the disk so just doing it dumbly might end up with a lot of seeking. I suppose you would at least need some tweaks to the scheduler to make sure it doesn't give these reads any priority and keeps them in the queue long enough to get real good sorting and large requests. Problem is that this would likely need to be asynchronous to be any useful unless you were willing to block a thread for a potentially long time for each file to be prefetched. -Andi - 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/