From: Con Kolivas <kernel@kolivas.org>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/33] Adaptive read-ahead V12
Date: Sat, 27 May 2006 10:00:11 +1000
User-Agent: KMail/1.9.1
Cc: Folkert van Heusden <folkert@vanheusden.com>, Andi Kleen <ak@suse.de>,
       Andrew Morton <akpm@osdl.org>, wfg@mail.ustc.edu.cn, mstone@mathom.us
References: <348469535.17438@ustc.edu.cn> <p73irns7uoh.fsf@bragg.suse.de> <20060526235436.GD4294@vanheusden.com>
In-Reply-To: <20060526235436.GD4294@vanheusden.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200605271000.12061.kernel@kolivas.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1168
Lines: 25

On Saturday 27 May 2006 09:54, Folkert van Heusden wrote:
> > > These are nice-looking numbers, but one wonders.  If optimising
> > > readahead makes this much difference to postgresql performance then
> > > postgresql should be doing the readahead itself, rather than relying
> > > upon the kernel's ability to guess what the application will be doing
> > > in the future.  Because surely the database can do a better job of that
> > > than the kernel.
> >
> > With that argument we should remove all readahead from the kernel?
> > Because it's already trying to guess what the application will do.
> > I suspect it's better to have good readahead code in the kernel
> > than in a zillion application.
>
> Maybe a pluggable read-ahead system could be implemented.

Pluggable anything is unpopular with Linus and other maintainers. See 
pluggable cpu scheduler and pluggable page replacement policy (vm) patchsets.

-- 
-ck
-
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/