Re: 2.6.23-rc1-mm2 (vm-dont-run-touch_buffer-during-buffercache-lookups.patch)

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 01 Aug 2007 03:36:30 -0400 Eric St-Laurent <ericstl34@sympatico.ca> wrote:

> On Tue, 2007-31-07 at 23:09 -0700, Andrew Morton wrote:
> 
> > +vm-dont-run-touch_buffer-during-buffercache-lookups.patch
> > 
> >  A little VM experiment.  See changelog for details.
> 
> > We don't have any tests to determine the effects of this, and nobody will
> > bother setting one up, so ho hum, this remains in -mm for ever.
> 
> > I don't think there's any point in doing this until we have some decent
> > testcases.
> 
> 
> Hi Andrew,
> 
> 
> For which problem this patch was coded?

Good question.  I think the current behaviour is just wrong.  What the
effect of changing it will be is hard to predict - probably little.

>  Is it a potential fix to the
> updatedb problem?

That's one workload which is particularly susceptible to the problemn which
that patch addresses, yes.  But in my (brief) testing it didn't make musch
difference.

> Is the patch effective without the filesystem dependant change you talk
> about?  (I use reiserfs)

Yes, it'll work as designed with reiserfs.

> I've been thinking about a test case for the updatedb problem:
> 
> 1. Script or program that create a large number of directories and zero
> sized files.  Same setup for everyone to have reproducible results.
> 
> 2. Run updatedb on those.
> 
> 3. Observe the effects (with vmstat, slabinfo and meminfo) before,
> during and after the updatedb run.
> 
> 4. Do something to trigger some reclaim like copying a large file.
> 
> 5. See the effects.
> 
> 
> What do you think? What would be the ideal test case for the problem in
> your opinion?

Sounds good, yes.

Or you could do something more real-worldly like start up OO, firefox and
friends, then run /etc/cron.daily/everything and see what the
before-and-after effects are.  The aggregate info we're looking for is
captured in /proc/meminfo: swapped, Mapped, Cached, Buffers.