From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA29Cbus026694 for ; Wed, 2 Nov 2005 04:12:38 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA29CbXg505894 for ; Wed, 2 Nov 2005 02:12:37 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jA29CbDG032514 for ; Wed, 2 Nov 2005 02:12:37 -0700 Reply-To: Gerrit Huizenga From: Gerrit Huizenga Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 In-reply-to: Your message of Wed, 02 Nov 2005 19:50:15 +1100. <43687DC7.3060904@yahoo.com.au> Date: Wed, 02 Nov 2005 01:12:30 -0800 Message-Id: Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Ingo Molnar , Kamezawa Hiroyuki , Dave Hansen , Mel Gorman , "Martin J. Bligh" , Andrew Morton , kravetz@us.ibm.com, linux-mm , Linux Kernel Mailing List , lhms List-ID: On Wed, 02 Nov 2005 19:50:15 +1100, Nick Piggin wrote: > Gerrit Huizenga wrote: > > > So, people are working towards two distinct solutions, both of which > > require us to do a better job of defragmenting memory (or avoiding > > fragementation in the first place). > > > > This is just going around in circles. Even with your fragmentation > avoidance and memory defragmentation, there are still going to be > cases where memory does get fragmented and can't be defragmented. > This is Ingo's point, I believe. > > Isn't the solution for your hypervisor problem to dish out pages of > the same size that are used by the virtual machines. Doesn't this > provide you with a nice, 100% solution that doesn't add complexity > where it isn't needed? So do you see the problem with fragementation if the hypervisor is handing out, say, 1 MB pages? Or, more likely, something like 64 MB pages? What are the chances that an entire 64 MB page can be freed on a large system that has been up a while? And, if you create zones, you run into all of the zone rebalancing problems of ZONE_DMA, ZONE_NORMAL, ZONE_HIGHMEM. In that case, on any long running system, ZONE_HOTPLUGGABLE has been overwhelmed with random allocations, making almost none of it available. However, with reasonable defragmentation or fragmentation avoidance, we have some potential to make large chunks available for return to the hypervisor. And, that same capability continues to help those who want to remove fixed ranges of physical memory. gerrit -- 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