From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46A98A14.3040300@gmail.com> Date: Fri, 27 Jul 2007 08:00:52 +0200 From: Rene Herman MIME-Version: 1.0 Subject: Re: updatedb References: <367a23780707250830i20a04a60n690e8da5630d39a9@mail.gmail.com> <46A773EA.5030103@gmail.com> <46A81C39.4050009@gmail.com> <7e0bae390707252323k2552c701x5673c55ff2cf119e@mail.gmail.com> <9a8748490707261746p638e4a98p3cdb7d9912af068a@mail.gmail.com> In-Reply-To: <9a8748490707261746p638e4a98p3cdb7d9912af068a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Jesper Juhl Cc: Andika Triwidada , Robert Deaton , linux-kernel@vger.kernel.org, ck list , linux-mm@kvack.org List-ID: On 07/27/2007 02:46 AM, Jesper Juhl wrote: > On 26/07/07, Andika Triwidada wrote: >> Might be insignificant, but updatedb calls find (~2M) and sort (~26M). >> Definitely not RAM intensive though (RAM is 1GB). > > That doesn't match my box at all : [ ... ] > This is a Slackware Linux 12.0 system. Yes, already identified that there are more updatedb's around. We are using "Secure Locate" and others simply the locate from the GNU findutils. Either version does not itself use significant memory though and seems irrelevant to the orginal swap-prefetch issue -- if updatedb filled memory with inodes and dentries the memory is no longer free and swap-prefetch can't prefetch anything. The remaining issue of updatedb unnecessarily blowing away VFS caches is being discussed (*) in a few thread-branches still running. Rene. (*) I so much wanted to say "buried". -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org