[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070727232919.GA8960@one.firstfloor.org>
Date: Sat, 28 Jul 2007 01:29:19 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Björn Steinbrink <B.Steinbrink@....de>,
Rene Herman <rene.herman@...il.com>,
Daniel Hazelton <dhazelton@...er.net>,
Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
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]
> Any faults in that reasoning?
GNU sort uses a merge sort with temporary files on disk. Not sure
how much it keeps in memory during that, but it's probably less
than 150MB. At some point the dirty limit should kick in and write back the
data of the temporary files; so it's not quite the same as anonymous memory.
But it's not that different given.
It would be better to measure than to guess. At least Andrew's measurements
on 128MB actually didn't show updatedb being really that big a problem.
Perhaps some people have much more files or simply a less efficient
updatedb implementation?
I guess the people who complain here that loudly really need to supply
some real numbers.
-Andi
-
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