[Discuss] Limiting amount of memory

[Bill Bogstad]

On Fri, Sep 13, 2013 at 7:24 PM, Richard Pieri <richard.pieri at gmail.com> wrote:
> Bill Bogstad wrote:
>>
>> I think you should do a reboot, capture the output of dmesg ("dmesg >
>> foo"), and  see what the kernel is saying about memory.
>
>
> No, I think Scott nailed it. I checked a couple of my Dell servers. Sure
> enough, the kernels report less RAM than is physically installed.

It would still be nice to know where the memory is being used.   I
attempted to look up info on the system in question (a Dell R710
server).   It is a 2U server with 18 DIMM slots.   Not the kind of
machine that I would expect to have a graphics implementation which is
going to hide gigabytes of RAM from the OS.

The details don't seem right to me either.   He has 48Gig of physical
RAM in the machine.   When he tells the kernel to use 8Gig, he ends up
with 6Gig.   When he tells it to use 16Gig, he ends up with 9Gig.  So
somehow the firmware/hardware is hiding different amounts of  RAM from
the OS, depending on how much RAM the OS is told is available for its
use.   Unless the firmware is parsing grub options (ha!), I don't see
how this can be blamed just on Dell hardware/firmware.   My gut
feeling is the that kernel (possibly a device driver) is somehow
involved here.   That's why I want to see the boot trace from dmesg.
Maybe some device driver is carving off a chunk of private RAM for
buffering which doesn't show up by the time one looks at
/proc/meminfo, but is visible at boot time.   If he can determine
which part of the kernel is doing this, he might even be able to
change it with a different grub option or at least understand how a
particular option to grub results in a different amount of free RAM.

Bill Bogstad