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/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:22 EST