From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 1 Nov 2005 15:46:22 +0100 From: Ingo Molnar Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 Message-ID: <20051101144622.GC9911@elte.hu> References: <20051030235440.6938a0e9.akpm@osdl.org> <27700000.1130769270@[10.10.2.4]> <4366A8D1.7020507@yahoo.com.au> <4366C559.5090504@yahoo.com.au> <4366D469.2010202@yahoo.com.au> <20051101135651.GA8502@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org Return-Path: To: Mel Gorman Cc: Nick Piggin , "Martin J. Bligh" , Andrew Morton , kravetz@us.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, lhms-devel@lists.sourceforge.net List-ID: * Mel Gorman wrote: > [...] The full 100% solution would be a large set of far reaching > patches that would touch a lot of the memory manager. This would get > rejected because the patches should have have arrived piecemeal. These > patches are one piece. To reach 100%, other mechanisms are also needed > such as; > > o Page migration to move unreclaimable pages like mlock()ed pages or > kernel pages that had fallen back into easy-reclaim areas. A mechanism > would also be needed to move things like kernel text. I think the memory > hotplug tree has done a lot of work here > o Mechanism for taking regions of memory offline. Again, I think the > memory hotplug crowd have something for this. If they don't, one of them > will chime in. > o linear page reclaim that linearly scans a region of memory reclaims or > moves all the pages it. I have a proof-of-concept patch that does the > linear scan and reclaim but it's currently ugly and depends on this set > of patches been applied. how will the 100% solution handle a simple kmalloc()-ed kernel buffer, that is pinned down, and to/from which live pointers may exist? That alone can prevent RAM from being removable. Ingo -- 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