TASK_UNMAPPED_BASE & stack location

TASK_UNMAPPED_BASE & stack location

[Martin J. Bligh]

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

Moreover, can we put the stack back where it's meant to be, below the
program text, in that wasted 128MB of virtual space? Who really wants 
> 128MB of stack anyway (and can't fix their app)?

I'm sure there's some horrible reason we can't do this ... would just like
to know what it is. If it's "standards compilance" I don't really believe
it - we don't comply with the standard now anyway ...

M.

PS. Motivation is creating large shmem segments for DBs.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: TASK_UNMAPPED_BASE & stack location

[badari]

Martin,

Only problem with moving TASK_UNMAPPED_BASE right above
text would be - limiting the malloc() space. malloc() is clever enough
to mmap() and do the right thing. Once I moved TASK_UNMAPPED_BASE
to 0x10000000 and I could not run some of the programs with large
data segments.

Moving stacks below text would be tricky. pthread library knows
the placement of stack. It uses this to distinguish between
threads and pthreads manager.

I don't know what other librarys/apps depend on this kind of stuff.

Thanks,
Badari

static inline pthread_descr thread_self (void)
{
#ifdef THREAD_SELF
  return THREAD_SELF;
#else
  char *sp = CURRENT_STACK_FRAME;
  if (sp >= __pthread_initial_thread_bos)
    return &__pthread_initial_thread;
  else if (sp >= __pthread_manager_thread_bos
           && sp < __pthread_manager_thread_tos)
    return &__pthread_manager_thread;
  else if (__pthread_nonstandard_stacks)
    return __pthread_find_self();
  else
#ifdef _STACK_GROWS_DOWN
    return (pthread_descr)(((unsigned long)sp | (STACK_SIZE-1))+1) - 1;
#else
    return (pthread_descr)((unsigned long)sp &~ (STACK_SIZE-1));
#endif
#endif
}


"Martin J. Bligh" wrote:

> 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 ...
>
> Moreover, can we put the stack back where it's meant to be, below the
> program text, in that wasted 128MB of virtual space? Who really wants
> > 128MB of stack anyway (and can't fix their app)?
>
> I'm sure there's some horrible reason we can't do this ... would just like
> to know what it is. If it's "standards compilance" I don't really believe
> it - we don't comply with the standard now anyway ...
>
> M.
>
> PS. Motivation is creating large shmem segments for DBs.
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: TASK_UNMAPPED_BASE & stack location

[William Lee Irwin III]

On Fri, Apr 25, 2003 at 04:52:05PM -0700, badari wrote:
> Only problem with moving TASK_UNMAPPED_BASE right above
> text would be - limiting the malloc() space. malloc() is clever enough
> to mmap() and do the right thing. Once I moved TASK_UNMAPPED_BASE
> to 0x10000000 and I could not run some of the programs with large
> data segments.
> Moving stacks below text would be tricky. pthread library knows
> the placement of stack. It uses this to distinguish between
> threads and pthreads manager.
> I don't know what other librarys/apps depend on this kind of stuff.

STACK_TOP is easy to change to see what goes wrong; it's a single
#define in include/asm-i386/a.out.h

Someone should spin it up and see how well pthreads copes.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: TASK_UNMAPPED_BASE & stack location

[Rik van Riel]

On Fri, 25 Apr 2003, Martin J. Bligh wrote:

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

What could be done is leave the stack where it is, but have
malloc() space and mmap() space grow towards each other:

0                                            3G
| |prog | malloc -->         <-- mmap | stack |

The stack will get the stack size ulimit size and the space
between where malloc and mmap start should be about 2.7 GB.

That 2.7 GB will of course by divided between malloc and mmap,
but the division will be done dynamically based on whoever
needs the space.  Much better than the current static 1:1.7
division...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: TASK_UNMAPPED_BASE & stack location

[William Lee Irwin III]

On Fri, 25 Apr 2003, Martin J. Bligh wrote:
>> 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 ...

On Sat, Apr 26, 2003 at 10:37:11AM -0400, Rik van Riel wrote:
> What could be done is leave the stack where it is, but have
> malloc() space and mmap() space grow towards each other:
> 0                                            3G
> | |prog | malloc -->         <-- mmap | stack |
> The stack will get the stack size ulimit size and the space
> between where malloc and mmap start should be about 2.7 GB.
> That 2.7 GB will of course by divided between malloc and mmap,
> but the division will be done dynamically based on whoever
> needs the space.  Much better than the current static 1:1.7
> division...

My internal proposals (backed by code) already include this in addition
to relocating the stack (whose kernel side is trivial).


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>