[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070727030040.0ea97ff7.akpm@linux-foundation.org>
Date: Fri, 27 Jul 2007 03:00:40 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
Frank Kingswood <frank@...gswood-consulting.co.uk>,
Andi Kleen <andi@...stfloor.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Ray Lee <ray-lk@...rabbit.org>,
Jesper Juhl <jesper.juhl@...il.com>,
ck list <ck@....kolivas.org>, Paul Jackson <pj@....com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans
for 2.6.23]
On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:
> More sophisticated testing is needed - there's something in
> ext3-tools which will mmap, page in and hold a file for you.
So much for that theory. afaict mmapped, active pagecache is immune to
updatedb activity. It just sits there while updatedb continues munching
away at the slab and blockdev pagecache which it instantiated. I assume
we're never getting the VM into enough trouble to tip it over the
start-reclaiming-mapped-pages threshold (ie: /proc/sys/vm/swappiness).
Start the updatedb on this 128MB machine with 80MB of mapped pagecache, it
falls to 55MB fairly soon and then never changes.
So hrm. Are we sure that updatedb is the problem? There are quite a few
heavyweight things which happen in the wee small hours.
-
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