lkml.org 
[lkml]   [2003]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: TASK_UNMAPPED_BASE & stack location
    From
    Date
    "Martin J. Bligh" <mbligh@aracnet.com> writes:

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

    > I've moved PAGE_OFFSET around 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:35    [W:0.020 / U:30.860 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site