moving on, more questions about HIGHMEM, and kernel addressing (some
of which we've discussed before, but i just want to make sure of this
again.)
given a typical 32-bit system, and the standard 3G/1G user/kernel
split of that 4G address space, that gives the kernel exactly 1G of
address space to work with, which is the set of virtual addresses at
0xC0000000 and up (that is, the interval [3G, 4G)).
that entire address range are referred to as "virtual" addresses,
since they *all* have to be mapped in some way, but the addresses
above and below the HIGHMEM boundary are treated differently.
generally, the virtual addresses in the interval [3G, 3G+896M) are
mapped to physical addresses simply by subtracting the offset of 3G,
so these are additionally referred to as "logical" addresses (in
hindsight, not a terrific choice of name but it seems to have caught
on). that leaves the kernel address space of [3G+896, 4G) -- HIGHMEM
-- as the only way to refer to physical memory above 1G and,
obviously, for which extra address translation needs to be done. so
far, so good?
so, some questions?
* if i absolutely *know* that i'm building a kernel for a system that
doesn't have more than 1G of RAM, do i need HIGHMEM at all? i can, of
course, deselect it during kernel configuration, but are there any
adverse effects to doing that other than making any RAM above 1G
inaccessible?
* since i can set the HIGHMEM boundary at boot time with "vmalloc=",
do i get the same effect with "vmalloc=0"? and, again, if i have <=1G
of RAM, would it cause any problems?
* if i boot a regular kernel with HIGHMEM support on a system with
less than 1G, can i assume that no space at all will be allocated for
high memory since it would be totally pointless?
thanks. i have to explain all this stuff to some folks in a week or
so, so i figure i might as well understand it myself. :-)
rday
p.s. i'm perusing the contents of /proc/meminfo -- i'm guessing that,
once i understand all that, i'll understand MM much better.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
