Messages in this thread | | | From | Rob Landley <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 | Date | Sat, 12 Nov 2005 20:30:35 -0600 |
| |
On Monday 07 November 2005 17:38, you wrote: > >>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.
Actually, what I was thinking is that if you use the swsusp infrastructure to suspend all processes, all dma, quiesce the heck out of the devices, and _then_ try to move the kernel... Well, you at least have a much more controlled problem. Yeah, it's pretty darn intrusive, but if you're doing "suspend to ram" perhaps the downtime could be only 5 or 10 seconds...
I don't know how much of the problem that leaves unsolved, though.
Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |