Mulyadi Santosa wrote:
Hello everybody
As we all know, using 3G/1G VM split (3G for user space, 1G for kernel
space), Linux kernel can only do the identity mapping on the first 896
MB of available RAM and the rest is considered as highmem.
Now let's assume we have a PC with 1GB RAM and we disable highmem
support in currently running Linux kernel. Also assume there is still
around 900 MB free RAM available to be used (it's currently consumed by
kernel code and data, also several user space daemons)
When a task is keep allocating memory (and the page frames are really
allocated, so it's not just a matter of extending the size of existing
VMA region such as heap) and it reaches 896 MB mark, can it keep asking
for more RAM?
Sure. The kernel will swap out some frames, if necessary, to fulfill the
request.
My understanding so far is: user space memory allocation is satisfied by
using free pages from ZONE_NORMAL pool. Since ZONE_NORMAL is ranging
from 16 MB to 896 MB, once it is all used, kernel memory allocator will
start looking in ZONE_HIGHMEM. But since we disable highmem support,
ZONE_HIGHMEM isn't exist. Therefore, the kernel can't satisfy user
space request beyond 896 MB, thus it failed. My other understanding is,
128 MB of RAM is simply wasted since it can't be addressed
"Used" doesn't necessarily mean "locked in RAM". If the kernel needs to
allocare a page, it will
kick an existing page out of RAM to do so (try_to_free_pages(), unless
that's vanished since
2.4 days). Of course, if all those pages are actively in use, the
machine will thrash -- swapped-out
pages will continue to be referenced by running code, but to swap them
back into RAM the kernel
will have to evict some other in-use pages, and ends up spending most of
its time reading and writing
the swapfile.
Cheers,
-- JK
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
