Messages in this thread | | | From | Raymond Nijssen <> | Date | Tue, 7 Sep 1999 23:09:38 -0700 (PDT) | Subject | DE-fragmenting the virtual memory map |
| |
While doing some experiments with large memory on linux-2.0.x on x86 I noticed that the virtual memory space is unnecessarily fragmented. This makes it harder to deal with very large objects. The main problem is due to the shared libraries being stored at the max heap address of 1GB.
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/
| |