Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

Joel Schopp
2005-11-07T23:38:20Z

>>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.
>
<snip>
> 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.