From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965256AbXG0X3d (ORCPT ); Fri, 27 Jul 2007 19:29:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756499AbXG0X3Z (ORCPT ); Fri, 27 Jul 2007 19:29:25 -0400 Received: from one.firstfloor.org ([213.235.205.2]:49870 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760890AbXG0X3Y (ORCPT ); Fri, 27 Jul 2007 19:29:24 -0400 Date: Sat, 28 Jul 2007 01:29:19 +0200 From: Andi Kleen To: =?iso-8859-1?Q?Bj=F6rn?= Steinbrink , Rene Herman , Daniel Hazelton , Mike Galbraith , Andrew Morton , Ingo Molnar , Frank Kingswood , Andi Kleen , Nick Piggin , Ray Lee , Jesper Juhl , ck list , Paul Jackson , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23] Message-ID: <20070727232919.GA8960@one.firstfloor.org> References: <9a8748490707231608h453eefffx68b9c391897aba70@mail.gmail.com> <20070727030040.0ea97ff7.akpm@linux-foundation.org> <1185531918.8799.17.camel@Homer.simpson.net> <200707271345.55187.dhazelton@enter.net> <46AA3680.4010508@gmail.com> <20070727231545.GA14457@atjola.homenet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070727231545.GA14457@atjola.homenet> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 28 Jul 2007 01:29:19 +0200 From: Andi Kleen Subject: Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23] Message-ID: <20070727232919.GA8960@one.firstfloor.org> References: <9a8748490707231608h453eefffx68b9c391897aba70@mail.gmail.com> <20070727030040.0ea97ff7.akpm@linux-foundation.org> <1185531918.8799.17.camel@Homer.simpson.net> <200707271345.55187.dhazelton@enter.net> <46AA3680.4010508@gmail.com> <20070727231545.GA14457@atjola.homenet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070727231545.GA14457@atjola.homenet> Sender: owner-linux-mm@kvack.org Return-Path: To: =?iso-8859-1?Q?Bj=F6rn?= Steinbrink , Rene Herman , Daniel Hazelton , Mike Galbraith , Andrew Morton , Ingo Molnar , Frank Kingswood , Andi Kleen , Nick Piggin , Ray Lee , Jesper Juhl , ck list , Paul Jackson , linux-mm@kvack.org, linux-kernel@vger.kernel.org List-ID: > 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, 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