On Fri, 15 Feb 2002, Martin Knoblauch wrote:
> Mark Goodwin wrote:
> >
> The kernel keeps a variable "max_mapnr" which seems to be the number of
> "mapped" physical memory pages. This is closer, but still 16, 32, 64,
> 128 or 256 KB off (I have seen all of these numbers). If you take this
> number and rond it to the next MB/GB, you probably have a very good
> estimate.
Well I was looking for something more definite than "probably", but
it sounds like it's a better number than existing MemTotal. However,
if MemTotal is supposed to be "total physical RAM installed", then we
should fix it so it reports the right number (if that is indeed possible).
If the correct interpretation is "total memory available to the kernel
and userland after the kernel has pinched a bit", then we need to add
new field, say "PhysMem".
>
> MemTotal: 1029196 kB => 1005.074 MB
> MaxMapped: 1048560 kB => 1023.984 MB (16 KB difference)
>
> So it seems the number is pretty reasonable. Of course, it would be
> cool to find a place that accounts the missing bits.
yes we should try and find the missing bits (a mystery to be solved).
> Should I try to
> submit that patch to the kernel and take the flaming about bloat :-)
how about we work out the real answer, and then submit a patch?
>
> "dmesg" shows the following line after booting, which also has the
> max_mapnr number:
>
> Memory: 320644k/327552k available (1421k kernel code, 6520k reserved,
> 425k data, 232k init, 0k highmem)
> ----------------^^^^^^
>
> Disadvantage is that it may get out of site after extended uptime when
> dmesg fills with other stuff.
during init we can save something like physmem = (available+init+1024) >> 20
and then report it in /proc/meminfo as Physmem: in units of mbytes.
thanks
-- Mark
|