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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070801004625.46a24a26.akpm@linux-foundation.org>
Date:	Wed, 1 Aug 2007 00:46:25 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Eric St-Laurent <ericstl34@...patico.ca>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc1-mm2
 (vm-dont-run-touch_buffer-during-buffercache-lookups.patch)

On Wed, 01 Aug 2007 03:36:30 -0400 Eric St-Laurent <ericstl34@...patico.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.


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