Mark Goodwin wrote:
>
> On Thu, 14 Feb 2002, Uncle Than wrote:
>
> > I had been under the assumption that
> >
> > mem.physmem = mem.util.free + mem.util.shared + mem.util.cached +
> > mem.util.bufmem.
>
> Also notice physmem as reported in /proc/meminfo does not
> correspond to real physical mem; it's almost the same, but does
> not account for a small amount of mem reserved by the kernel.
> A way to figure out the exact amount still eludes me .. anyone know?
>
I think (if we are talking about IA32 Systems with a BIOS), exact will
be almost impossible. The first number in the "Mem:" line or the
"MemTotal:" number are close, but not the physical memory.
One solution could be to add up all lines with in /proc/mtrr with
"write-back" in them. I checked it out on a few system. Those with
kernels > 2.4.7-ac9 produce the right number. Earlier ones (2.4.2)
produce complete nonsense :-( Also availability /proc/mtrr seems to be
configuration dependent. But so is the whole /proc FS, of course.
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.
I am running the following patch on top of 2.4.18pre8 just now on my
320 MB notebook:
-xxx> diff -u fs/proc/proc_misc.c.orig fs/proc/proc_misc.c
--- fs/proc/proc_misc.c.orig Fri Feb 15 15:28:32 2002
+++ fs/proc/proc_misc.c Fri Feb 15 15:32:00 2002
@@ -170,7 +170,8 @@
"LowTotal: %8lu kB\n"
"LowFree: %8lu kB\n"
"SwapTotal: %8lu kB\n"
- "SwapFree: %8lu kB\n",
+ "SwapFree: %8lu kB\n"
+ "MaxMapped: %8lu kB\n",
K(i.totalram),
K(i.freeram),
K(i.sharedram),
@@ -184,7 +185,8 @@
K(i.totalram-i.totalhigh),
K(i.freeram-i.freehigh),
K(i.totalswap),
- K(i.freeswap));
+ K(i.freeswap),
+ K(max_mapnr));
return proc_calc_metrics(page, start, off, count, eof, len);
#undef B
The relevant lines on my Notebook show:
MemTotal: 320876 kB => 313.355 MB
MaxMapped: 327552 kB => 319.875 MB (128 KB difference)
On a 1GB dula P-III System it loks like:
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. Should I try to
submit that patch to the kernel and take the flaming about bloat :-)
"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.
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
|