TASK_UNMAPPED_BASE & stack location
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Martin J. Bligh
Quoted 6 lines
Quoted 3 lines
Is there any good reason we can't remove
TASK_UNMAPPED_BASE, and just shove libraries directly above the program text? Red Hat seems to have patches to dynamically tune it on a per-processes basis anyway ...Yes. You won't get a continuous sbrk/brk heap then anymore. Not sure it is a big problem though.
Me no understand. I think this *makes* it a contiguous space. The way I see it, we currently allocate from
TASK_UNMAPPED_BASEup to the top, then start again above program text. Which seems a bit silly.
The space for brk is not completely continuous anymore, especially when you use mmap() too.
Same with mmap.
Basically mmap() and brk/sbrk (=malloc) will fragment each other.
wli's suggestion of making it a personality makes sense.
Quoted 5 lines
I've moved
PAGE_OFFSETaround a lot (which moves the stack, as you say). Haven't seen it break anything yet ... IMHO it was broken anyway if this hurts it. Obviously not something one could do in a stable kernel series, but 2.5 seems like a perfect time for it to me ... unless I'm missing some glibc / linker thing, it seems like a simple change.
It at least broke Sun Java.
-Andi
Quoted 9 lines · Andi Kleen
Quoted 5 lines
I've moved
PAGE_OFFSETaround a lot (which moves the stack, as you say). Haven't seen it break anything yet ... IMHO it was broken anyway if this hurts it. Obviously not something one could do in a stable kernel series,
but 2.5 seems like a perfect time for it to me ... unless I'm missing some
glibc / linker thing, it seems like a simple change.It at least broke Sun Java.
That has been fixed in latest JDK.