On Thu, 26 Apr 2007 00:04:00 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> If this new algorithm has been further tested and approved, I'll
> re-submit the patch in a cleaner, standalone form. The adaptive
> readahead patches can be dropped then. They may better be reworked as
> a kernel
On Thu, 26 Apr 2007 00:04:00 +0800 Fengguang Wu [EMAIL PROTECTED] wrote:
If this new algorithm has been further tested and approved, I'll
re-submit the patch in a cleaner, standalone form. The adaptive
readahead patches can be dropped then. They may better be reworked as
a kernel module.
On Wed, Apr 25, 2007 at 06:08:44PM +0200, Andi Kleen wrote:
> > Yeah, the on-demand readahead can avoid _all_ lookups for small in-cache
> > files.
>
> How?
In filemap.c:
if (!page) {
page_cache_readahead_adaptive(mapping,
> Yeah, the on-demand readahead can avoid _all_ lookups for small in-cache
> files.
How?
> But what do you mean by AS?
struct address_space
> > You seem to have a lot of magic numbers. They probably all need symbols and
> > explanations.
>
> The magic numbers are for easier testings, and
On Wed, Apr 25, 2007 at 04:37:41PM +0200, Andi Kleen wrote:
> Fengguang Wu <[EMAIL PROTECTED]> writes:
>
> > OVERHEADS
> >
> > The new code reduced the overheads of
> >
> > - excessively calling the readahead routine on small sized reads
> > (the current readahead code insists on
Fengguang Wu <[EMAIL PROTECTED]> writes:
> OVERHEADS
>
> The new code reduced the overheads of
>
> - excessively calling the readahead routine on small sized reads
> (the current readahead code insists on seeing all requests)
>
> - doing a lot of pointless page-cache
Andrew,
This is a minimal readahead algorithm that aims to replace the current one.
It is more flexible and reliable, while maintaining almost the same behavior
and performance. Also it is full integrated with adaptive readahead.
It is designed to be called on demand:
- on a missing
Andrew,
This is a minimal readahead algorithm that aims to replace the current one.
It is more flexible and reliable, while maintaining almost the same behavior
and performance. Also it is full integrated with adaptive readahead.
It is designed to be called on demand:
- on a missing
Fengguang Wu [EMAIL PROTECTED] writes:
OVERHEADS
The new code reduced the overheads of
- excessively calling the readahead routine on small sized reads
(the current readahead code insists on seeing all requests)
- doing a lot of pointless page-cache lookups for
On Wed, Apr 25, 2007 at 04:37:41PM +0200, Andi Kleen wrote:
Fengguang Wu [EMAIL PROTECTED] writes:
OVERHEADS
The new code reduced the overheads of
- excessively calling the readahead routine on small sized reads
(the current readahead code insists on seeing all requests)
Yeah, the on-demand readahead can avoid _all_ lookups for small in-cache
files.
How?
But what do you mean by AS?
struct address_space
You seem to have a lot of magic numbers. They probably all need symbols and
explanations.
The magic numbers are for easier testings, and will be
On Wed, Apr 25, 2007 at 06:08:44PM +0200, Andi Kleen wrote:
Yeah, the on-demand readahead can avoid _all_ lookups for small in-cache
files.
How?
In filemap.c:
if (!page) {
page_cache_readahead_adaptive(mapping,
12 matches
Mail list logo
