Messages in this thread | | | Date | Sun, 6 May 2001 14:02:54 +1200 | From | Chris Wedgwood <> | Subject | Re: [PATCH] CPU hot swap for 2.4.3 + s390 support |
| |
On Sat, May 05, 2001 at 08:08:59PM -0400, Peter Rival wrote:
Hrmm... I agree this is a hard problem. I know people smarter than I have been thinking about this type of problem at Compaq.
It's hard with current memory allocation and management paradigms, if we wanted to abstract things more and make (break) certain rules, I'm sure it can me made to work -- the only thing is, we would loose _MUCH_ speed and efficiency (and waste much more space), so much so I doubt anyone would serious want to know about it.
We would also have to violate certain assumptions of RT applications.
While I haven't talked to them directly, my only guess would be that we'd have to hand-rewrite some page tables after copying the page contents to a new area.
That in itself isn't too bad, except if the pages are mlocked this is nasty, you have to block all access to the page during copy, very bad for RT stuff.
Not only that, what if the pages themselves have kernel allocations in them? We cannot find these (at present) let alone have _any_ idea how to move them. I guess it could be fidged to work using the MMU if we were allowed to _COMPLETELY_ lock the system duing the removal phase from all interrupts and such like... seems pretty horrible to me.
It's late Saturday and I really haven't thought this through fully, so I'm not even sure that would work, but it's something like how we support replicated text segments on our GS series...don't know why it wouldn't work here. *shrug*
There have been demonstrations in the past of this sort of thing. I think HP may have done one. Not with a commodity OS though.
Actually, I just thought of a kill, what about platforms that have physically mapped page-tables? This makes like even harder as you have to move them :(
It's the IBM technology that works around bad memory by detecting single-bit errors and removing the chip that caused it from use.
I think Solaris claims to do this right now... no idea if it works, I know of at least one Solaris 7 machine with a dicky memory bit and it keeps moaning about parity corrections so I guess it doesn't lock it out. Maybe later versions (8) do?
I'd think of this as a big hammer version of that in software.
It's much easier to do in hardware with current OS design I should think.
Besides, eventually you'll want to replace the DIMM that has the bad chip, and what better way then while the system is still running (as long as it's stable, of course ;) I'm just thinking out loud, so someone can correct me if I'm being loopy...
Again, you could do this is hardware... have the hardware route writes to the memory elsewhere and only take reads from the old memory until the 'refresh' cycles have copied all the data over. Hmm, when I think about this, doing this in the memory controller chipset seems much easier I wonder if someone hasn't actually done it...
--cw - 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/
| |