Re: heap-stack-gap for 2.6

[Arjan van de Ven <arjanv@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Wed, Sep 29, 2004 at 12:19:33AM +0200, Andrea Arcangeli wrote:
> On Tue, Sep 28, 2004 at 09:43:51PM +0200, Arjan van de Ven wrote:
> > On Mon, Sep 27, 2004 at 03:09:19PM +0200, Andrea Arcangeli wrote:
> > > > which "those apps" ?
> > > 
> > > those apps that wants to allocate as close as possible to the stack.
> > > They're already using /proc/self/mapped_base, the gap of topdown isn't
> > > configurable.
> > 
> > /proc/self/mmaped_base doesn't exist...
> 
> it does with this patch that should be included in mainline too. This
> follows the redhat API that oracle requires (you invented it, didn't
> you?) so you should be fine with it.

> with mapped base people is free to allocate as much memory as the
> hardware can, with topdown not.

oh? you mean that 1Mb gap between stack and topdown? Every ISV I talked to
said they could get more VA space with topdown than with the suse
mmaped_base hack... :)

> Yeah, map fix is map fixed and when you execute map fixed on a existing
> mapping becaue topdown moved below the 1G mark (a place where there
> could never have been a "hinted" mapping before), the existing mapping
> will be destroyed and the application will behave randomly.

MAP_FIXED is to be used only on things YOU mmaped before. 
> 
> isn't the whole point of topdown to gain ~1G more of RAM. A 1G area that
> couldn't possibly be used before

wrong; brk() is there which is also used by malloc() and internally by the C
library.

> mallocs. topdown breaks that assumption and can break random apps in
> random ways.

do you have proof for that?

 
> Or did I misunderstood something? If topdown still forbids you to use
> the first 1G of address space, then what's the point?!?

You missed that you can only use MAP_FIXED on mmaps YOU mmaped before.
That's true for basically all operating systems because the runtime
(including C library) is allowed to malloc, to brk(), to mmap etc etc.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]