[lkml]   [2007]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 17:06:50 wrote:
> On Sat, 28 Jul 2007, Daniel Hazelton wrote:
> > On Saturday 28 July 2007 04:55:58 wrote:
> >> On Sat, 28 Jul 2007, Rene Herman wrote:
> >>> On 07/27/2007 09:43 PM, wrote:
> >>>> On Fri, 27 Jul 2007, Rene Herman wrote:
> >>>>> On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
> >>
> >> nobody is arguing that swap prefetch helps in the second cast.
> >
> > Actually, I made a mistake when tracking the thread and reading the code
> > for the patch and started to argue just that. But I have to admit I made
> > a mistake - the patches author has stated (as Rene was kind enough to
> > point out) that swap prefetch can't help when memory is filled.
> I stand corrected, thaks for speaking up and correcting your position.

If you had made the statement before I decided to speak up you would have been
correct :)

Anyway, I try to always admit when I've made a mistake - its part of my
philosophy. (There have been times when I haven't done it, but I'm trying to
make that stop entirely)

> >> what people are arguing is that there are situations where it helps for
> >> the first case. on some machines and version of updatedb the nighly run
> >> of updatedb can cause both sets of problems. but the nightly updatedb
> >> run is not the only thing that can cause problems
> >
> > Solving the cache filling memory case is difficult. There have been a
> > number of discussions about it. The simplest solution, IMHO, would be to
> > place a (configurable) hard limit on the maximum size any of the kernels
> > caches can grow to. (The only solution that was discussed, however, is a
> > complex beast)
> limiting the size of the cache is also the wrong thing to do in many
> situations. it's only right if the cache pushes out other data you care
> about, if you are trying to do one thing as fast as you can you really do
> want the system to use all the memory it can for the cache.

After thinking about this you are partially correct. There are those sorts of
situations where you want the system to use all the memory it can for caches.
OTOH, if those situations could be described in some sort of simple
heuristic, then a soft-limit that uses those heuristics to determine when to
let the cache expand could exploit the benefits of having both a limited and
unlimited cache. (And, potentially, if the heuristic has allowed a cache to
expand beyond the limit then, when the heuristic no longer shows the oversize
cache is no longer necessary it could trigger and automatic reclaim of that

(I'm willing to help write and test code to do this exactly. There is no
guarantee that I'll be able to help with more than testing - I don't
understand the parts of the code involved all that well)


Dialup is like pissing through a pipette. Slow and excruciatingly painful.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-28 23:51    [W:0.304 / U:4.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site