[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46A83C7A.80601@yahoo.com.au>
Date: Thu, 26 Jul 2007 16:17:30 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Ray Lee <ray-lk@...rabbit.org>,
Eric St-Laurent <ericstl34@...patico.ca>,
Rene Herman <rene.herman@...il.com>,
Jesper Juhl <jesper.juhl@...il.com>,
ck list <ck@....kolivas.org>, Ingo Molnar <mingo@...e.hu>,
Paul Jackson <pj@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: -mm merge plans for 2.6.23
Andrew Morton wrote:
> On Thu, 26 Jul 2007 15:53:37 +1000 Nick Piggin <nickpiggin@...oo.com.au> wrote:
>
>
>>Not that I want to say anything about swap prefetch getting merged: my
>>inbox is already full of enough "helpful suggestions" about that,
>
>
> give them the kernel interfaces, they can do it themselves ;)
It is a good idea if we can give enough to get started. Then if
they run into something they really need to do in the kernel, we
can take a look.
Page eviction order / prefetch-back-in-order might be tricky to
expose.
>>so I'll
>>just be happy to have a look at little things like updatedb.
>
>
> Yes, that is a little thing. I mean, even if the kernel's behaviour
> during an updatedb run was "perfect" (ie: does what we the designers
> curently intend it to do (whatever that is)) then the core problem isn't
> solved: short-term workload evicts your working set and you have to
> synchronously reestablish it.
Sure, I know and I was never against swap (and/or file) prefetching to
solve this problem. I'm just saying, I'm staying out of that :)
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists