From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA7NcH7O029268 for ; Mon, 7 Nov 2005 18:38:17 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA7NcHqu118326 for ; Mon, 7 Nov 2005 18:38:17 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jA7NcGsw028499 for ; Mon, 7 Nov 2005 18:38:17 -0500 Message-ID: <436FE561.7080703@austin.ibm.com> Date: Mon, 07 Nov 2005 17:38:09 -0600 From: Joel Schopp MIME-Version: 1.0 Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 References: <20051104010021.4180A184531@thermo.lanl.gov> <20051103221037.33ae0f53.pj@sgi.com> <20051104063820.GA19505@elte.hu> <796B585C-CB1C-4EBA-9EF4-C11996BC9C8B@mac.com> <20051107080042.GA29961@elte.hu> <1131361258.5976.53.camel@localhost> <20051107122009.GD3609@elte.hu> <1131392070.14381.133.camel@localhost.localdomain> In-Reply-To: <1131392070.14381.133.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Steven Rostedt Cc: Ingo Molnar , Nick Piggin , mel@csn.ul.ie, linux-mm , Linux Kernel Mailing List , lhms , kravetz@us.ibm.com, arjanv@infradead.org, arjan@infradead.org, Andrew Morton , mbligh@mbligh.org, andy@thermo.lanl.gov, Paul Jackson , Kyle Moffett , Linus Torvalds , Dave Hansen List-ID: >>RAM removal, not RAM replacement. I explained all the variants in an >>earlier email in this thread. "extending RAM" is relatively easy. >>"replacing RAM" while doable, is probably undesirable. "removing RAM" >>impossible. > > BTW, I'm not suggesting any of this is a good idea, I just like to > understand why something _cant_ be done. > I'm also of the opinion that if we make the kernel remap that we can "remove RAM". Now, we've had enough people weigh in on this being a bad idea I'm not going to try it. After all it is fairly complex, quite a bit more so than Mel's reasonable patches. But I think it is possible. The steps would look like this: Method A: 1. Find some unused RAM (or free some up) 2. Reserve that RAM 3. Copy the active data from the soon to be removed RAM to the reserved RAM 4. Remap the addresses 5. Remove the RAM This of course requires step 3 & 4 take place under something like stop_machine_run() to keep the data from changing. Alternately you could do it like this: Method B: 1. Find some unused RAM (or free some up) 2. Reserve that RAM 3. Unmap the addresses on the soon to be removed RAM 4. Copy the active data from the soon to be removed RAM to the reserved RAM 5. Remap the addresses 6. Remove the RAM Which would save you the stop_machine_run(), but which adds the complication of dealing with faults on pinned memory during the migration. -- 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