> 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/