Date: Thu, 25 May 2006 15:26:20 -0400
From: Michael Stone <mstone@mathom.us>
Subject: Re: [PATCH 00/33] Adaptive read-ahead V12
In-reply-to: <20060525084415.3a23e466.akpm@osdl.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Wu Fengguang <wfg@mail.ustc.edu.cn>, linux-kernel@vger.kernel.org
Message-id: <20060525192618.GA27471@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <348469535.17438@ustc.edu.cn>
 <20060525084415.3a23e466.akpm@osdl.org>
User-Agent: Mutt/1.5.11+cvs20060403
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1212
Lines: 22

On Thu, May 25, 2006 at 08:44:15AM -0700, Andrew Morton 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.

In this particular case Wu had asked about postgres numbers, so I 
reported some postgres numbers. You could probably get similar speedups 
out of postgres by implementing readahead in postgres. OTOH, the kernel 
patch also gives substantial speedups to thing like cp; the question 
comes down to whether it's better for every application to implement 
readahead or for the kernel to do it. (There are, of course, other 
concerns like maintainability or whether performance degrades in other 
cases, but I didn't test that. :)

Mike Stone
-
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/