Messages in this thread | | | Date | Wed, 8 Sep 1999 11:23:46 -0400 (EDT) | From | Benjamin LaHaise <> | Subject | Re: DE-fragmenting the virtual memory map |
| |
On Tue, 7 Sep 1999, Raymond Nijssen wrote:
> 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.
You're missing a very important point: the normal implementation of malloc under linux makes use of mmap() to allocate blocks of memory. Personally, I consider brk() an obsolete interface because it just doesn't fit with the normal allocation/deallocation patterns of daemons and applications -- pages are not returned to the system that are otherwise unused, and end up needing to be swapped out. Note that by default, the space available for mmap()ing is just under 2GB on ia32. That's reasonable for a 32 bit architechure.
> 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.
MIN_mmap and min_stack can already be adjusted via RLIMIT_DATA and RLIMIT_STACK respectively, so there's actually no work needed to be done to the kernel. There have been a few patches in late 2.2 to make sure the adherence to these limits is correct, so be sure to update to 2.2.12.
-ben
- 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/
| |