A.P. Lawrence

Best of the Newsgroups: OSR5 kernel memory

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@sco.com>
Subject: Re: Who will provide the ram?
Date: Tue, 4 Nov 2003 21:41:46 GMT References: <20031102130911.A1126@egps.egps.com> <20031104085441.GO14056@sco.com> <20031104080930.A5287@egps.egps.com>

Nachman Yaakov Ziskind wrote:

>                         Memory used by Kernel
> 
> --> 0x00000000-0x00007fff       32 Kb   Kernel reserved
>     0x00008000-0x0009fbff      607 Kb   Unused
> --> 0x0009fc00-0x0009ffff        1 Kb   BIOS private area - Reserved
>     0x000a0000-0x000effff      320 Kb   Unused
> --> 0x000f0000-0x000fffff       64 Kb   BIOS private area - Reserved
>     0x00100000-0x00d90fff    12.57 Mb   Unused
> --> 0x00d91000-0x00ffffff     2.43 Mb   Kernel data
>     0x01000000-0x17e11fff   366.07 Mb   Unused
> --> 0x17e12000-0x17ffffff     1.93 Mb   Kernel text
>                                         Shadow ram & other special mem
>                                         Non-ISA-DMAable
>     0x18000000-0xfebfffff     3692 Mb   Unused
> --> 0xfec00000-0xfec0ffff       64 Kb   BIOS private area - Reserved
>     0xfec10000-0xfedfffff     1.94 Mb   Unused
> --> 0xfee00000-0xfee0ffff       64 Kb   BIOS private area - Reserved
>     0xfee10000-0xfff7ffff    17.44 Mb   Unused
> --> 0xfff80000-0xfffffffe      512 Kb   BIOS private area - Reserved
>                             ---------
>                               5.08 Mb   RAM total  (6 Mb - 939.001 Kb)
> 
> I *don't really understand the math here. It seems like all the numbers add up
> to 5.08 mb.

5.08Mb is the sum of the lines I marked "-->" above.  It's a silly
number -- sum of memory used by the initial loading of the kernel +
memory which was marked by the BIOS as unusable.  It's important for the
kernel to know about areas marked as BIOS-private, so it doesn't try to
find and allocate regular RAM there, but it makes no sense to lump the
two things together into a single sum.  Then it's additionally confusing
to throw these all out in a single table, interleaved with the unused
areas, and show a summation below which only sums some of the lines!

You'll notice that the BIOS has marked out various areas of different
sorts.  9FC00-9FFFF is regular RAM being used as private storage by the
BIOS.  F0000-FFFFF is BIOS ROM, likely overlaid with faster RAM in a
modern system, but that RAM will have been made read-only by the BIOS,
using the CPU's MTRRs (Memory Type and Range Registers).
FEC0xxxx are addresses used by an I/O APIC; FEE0xxxx are the local APIC;
FFF80000-FFFFFFFF I'm not sure.

Most of these are areas that will not contain RAM due to the inherent
design of the CPU and PC architecture.  So it's silly for `hw` to report
these as areas the kernel is "using", as if it chose to allocate them.

> But, no big chunk under BIOS private area - Reserved~

Right.  This means that booting with "mem=/v" probably won't show
anything, but you might want to do it anyway just to be sure.

> '3692 Mb  Unused' - eh?

This particular map is showing the entire 4GB 32-bit address space, with
usage information describing what the memory map looked like at kernel
startup time.  Because it's an address space map (rather than a RAM
map), "Unused" areas can represent present-but-unallocated RAM or
not-present RAM, which is what the 3692MB area is.

> Should I still do mem/v ? Can;t do it until tonight.

Up to you.  I suspect it will not add anything except to give you
slightly more detail on the BIOS private areas we already see.  But you
should be rebooting anyway so you can run more intensive diagnostics...

>Bela<

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Need eyes on the ground at your customer's site?
Installation and light training Boston and New England
Reliable and experienced, punctual and professional.

/Bofcusm/2376.html copyright 1997-2004 Bela Lubkin All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here