Re: heap-stack-gap for 2.6

From: Arjan van de Ven
Date: Wed Sep 29 2004 - 01:07:36 EST


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: pgp00000.pgp
Description: PGP signature