Mark Goodwin wrote:
>
> 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
I don't think it is supposed/guaranteed to be the physical memory
installed. To me it looks more like "total memory available to this
running kernel". Small :-) difference on ia32.
> 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".
>
correct. We need to find the bits and then report 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?
>
Agreed. What about the "mtrr" suggestion (for IA32)? On the systems I
checked, the sum of "write-back" entries was either correct, or complete
nonsense (on older 2.4 kernels).
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: Martin.Knoblauch@xxxxxxxxxxx
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
|