From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 03 Nov 2005 07:57:15 -0800 From: "Martin J. Bligh" Reply-To: "Martin J. Bligh" Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 Message-ID: <307350000.1131033435@[10.10.2.4]> In-Reply-To: References: <4366C559.5090504@yahoo.com.au> <4366D469.2010202@yahoo.com.au> <20051101135651.GA8502@elte.hu> <1130854224.14475.60.camel@localhost><20051101142959.GA9272@elte.hu> <1130856555.14475.77.camel@localhost><20051101150142.GA10636@elte.hu> <1130858580.14475.98.camel@localhost><20051102084946.GA3930@elte.hu> <436880B8.1050207@yahoo.com.au><1130923969.15627.11.camel@localhost> <43688B74.20002@yahoo.com.au><255360000.1130943722@[10.10.2.4]> <4369824E.2020407@yahoo.com.au> <306020000.1131032193@[10.10.2.4]> <1131032422.2839.8.camel@laptopd505.fenrus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mm@kvack.org Return-Path: To: Linus Torvalds , Arjan van de Ven Cc: Nick Piggin , Dave Hansen , Ingo Molnar , Mel Gorman , Andrew Morton , kravetz@us.ibm.com, linux-mm , Linux Kernel Mailing List , lhms , Arjan van de Ven List-ID: >> with CONFIG_4KSTACKS :) > > 2-page allocations are _not_ a problem. > > Especially not for fork()/clone(). If you don't even have 2-page > contiguous areas, you are doing something _wrong_, or you're so low on > memory that there's no point in forking any more. 64 bit platforms need kernel stacks > 8K, it seems. > Don't confuse "fragmentation" with "perfectly spread out page > allocations". > > Fragmentation means that it gets _exponentially_ more unlikely that you > can allocate big contiguous areas. But contiguous areas of order 1 are > very very likely indeed. It's only the _big_ areas that aren't going to > happen. > > This is why fragmentation avoidance has always been totally useless. It is > - only useful for big areas > - very hard for big areas > > (Corollary: when it's easy and possible, it's not useful). > > Don't do it. We've never done it, and we've been fine. Claiming that > fork() is a reason to do fragmentation avoidance is invalid. With respect, we have not been fine. We see problems fairly regularly with no large page/hotplug issues with higher order allocations. Drivers, CIFS, kernel stacks, etc, etc etc. The larger memory gets, the worse the problem is, just because the statistics make it less likely to free up multiple contiguous pages. M. -- 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