Hi ...
Thanks for your kind reply..... I really appreciate it. The discussion
still continues, however .... :)
This is what Fawaad said :
>Yes, 128MB is wasted due to not usage of HIGHMEM :) but kernel can
>satisfy the request of more memory as i mentioned above ! (CMIIW)
Anyway, I forgot to set another assumption. Assume that there is no swap
space at all, so it just pure 1GB RAM. Therefore, overcommit status is
ignored.
This makes me thinks, why kernel's limitation to directly map physical
RAM up to 896 MB (in 3G/1G split, 32 bit CPU) becomes user space
limitation too?
To be precise, here is code fragment from __alloc_pages() in
mm/page_alloc.c:
------------------------------------------------------------------------------
for (i = 0; (z = zones[i]) != NULL; i++) {
min = z->pages_low + (1<<order) +
z->protection[alloc_type];
if (z->free_pages < min)
continue;
page = buffered_rmqueue(z, order, gfp_mask);
if (page)
goto got_pg;
------------------------------------------------------------------------------
>From the above snippets, I come to conclusion that if there is no
ZONE_HIGHMEM, then the page allocator will search only on ZONE_DMA
(0-16 MB) and ZONE_NORMAL (16-896MB). __alloc_pages() is the "heart" of
memory allocator, so IMHO it is also executed when user space calls
malloc(). Maybe not directly, perhaps it is deferred until the page
frame is actually needed and thus allocated as many as needed.
Comments?
regards
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
