Re: Use of memmap= to forcibly recover memory in 3GB-4GB range - is this safe?

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, Jan 15, 2013 at 08:47:20PM -0500, Alex Villacís Lasso wrote:
> The system boots, apparently normally, and I can see the additional
> "memory" in all system reports. However, I cannot quite shake the
> feeling that this "memory" might be in fact an illusion, and an
> attempt to use it will wrap around to the bottom of the memory and
> corrupt anything there. Or worse.
> 
> Some tests that I have tried:
> 1) I have tried to occupy as much memory as possible, by starting
> two virtual machines, plus one instance of eclipse, a browser, and a
> bittorrent client, while running the graphical desktop. I have seen
> the free memory (as reported by "top") fall to under 200 Mb with no
> apparent instability, so this should prove that the extra memory is
> real, right?

If you ran all that and it didn't crash and burn, I'm thinking you are
pretty safe. I would think that if you had 768 megs mapped to nothing,
mirrored to other memory, or any number of other atrocities, your above
actions would most likely show some horrible failure.

I think you are correct in assuming that if the MTRR mappings shows
memory there, it may just be a bug in the BIOS that is not adding it.

> 2) I have recompiled the kernel to support the memtest parameter.
> When using it, the extra memory segment appears to be as healthy as
> other areas of memory. However this might only mean that it is
> wrapping into healthy low RAM.
> 
> Is my reasoning sane? Is there a way to know, once and for all,
> whether the extra "memory" is real and safe to use or not?

I can think of writing a kernel module that reads and writes to these
locations just to make sure. But other than that, I'm not aware of
anything. Maybe someone else could offer more.

-- Steve