I was wondering if this problem can be solved (at least on the x86 platforms)
by rearranging the virtual memory layout somewhat.
Currenly the virtual memory segmentation is as follows on x86 (2.0 and 2.2):
FROM - TO : PURPOSE
0xc0000000 - 0xffffffff : kernel memory
min_stack - 0xc0000000 : user stack -- grows downward
max_mmap - min_stack : (free)
0x40000000 - max_mmap : mapped (mmap, shared mem/libs) -- grows upward
'brk' - 0x40000000 : (free)
`end' - 'brk' : heap -- grows upward
0x00000000 - 'end' : text, bss, etc.
where `end' > 0x08000000 typically (fixed at load-time)
and max_stack = 0xc0000000 - 8MB by default. (fixed at load-time)
The limitations of this layout are:
1. the effective heap size of about only 0.8 GB. This is insufficient for
large processes. Even on WNT you get effectively about twice that,
and it is not enough either. Solaris/SPARC provides 3.75GB user vm.
2. the largest file that can possibly be mapped would be about 1.9 GB.
(in practice even less due to fragmentation after a while)
3. the initial segmentation already establishes a rigid fragmentation.
The proposal is to make the mappable region start at max_stack and to make it
grow downward. This scheme likens the approach used in Solaris/SPARC.
The proposed segmentation looks like:
0xc0000000 - 0xffffffff : kernel memory
min_stack - 0xc0000000 : user stack -- grows downward
MIN_mmap - min_stack : mapped (mmap, shared mem/libs) -- grows DOWNward
'brk' - MIN_mmap : (free)
`end' - 'brk' : heap -- grows upward
0x00000000 - 'end' : text, bss, etc.
Notice the single large free space.
The changes to the code look very simply but I don't know if there are any
non-obvious implications.
It seems like a worthwhile experiment at least.
Thanks,
-Raymond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/