TASK_UNMAPPED_BASE changes in 2.4.20 (r.h. 9)

From: Eric Taylor (et_at_rocketship1.com)
Date: 09/26/03


Date: Fri, 26 Sep 2003 19:10:16 GMT

Up to verion 2.4.18, I was able to relocate the libraries into high memory, just
below the stack, so my lower brk (or sbrk, i forget which one) area would
be contiguous (on intel 32 bit arch) between the top of the program area and the
libraries starting location.

In 2001 I submitted patches that would have let TASK_UNMAPPED_BASE be
a variable, and others submitted ways to make this a per project setting.
Unfortunately, no supported solution appears to have been found
to the need for large contiguous memory allocation in 32 bit systems.
The answer given mostly is to get a 64 bit system. Well, we cannot
do that for a few more years, and so I still need a fix for this.

It has now been quite some time since I had to deal with this, and I was
wondering what the latest issues are. I see that the value comes now from

 addr = mm->free_area_cache;

which I haven't been able to track down yet where this comes from (in
mmap.c).

This statement, in routine,

arch_get_unmapped_area(struct file *filp, unsigned long addr, ...

used to set addr to TASK_UNMAPPED_BASE, and I would simply
modify this to 0xb000_0000 (w/o the _'s) instead of the default of
0x4000_0000 as delivered. This one line fix was all I needed to do.

But now, I am stumped. Is it safe to make this same change? Is the
fact this is a variable now mean there is some way to set this, maybe
on a per process basis?

thanks
eric



Relevant Pages

  • TASK_UNMAPPED_BASE changes in 2.4.20 (r.h. 9)
    ... Up to verion 2.4.18, I was able to relocate the libraries into high memory, just ... used to set addr to TASK_UNMAPPED_BASE, ... This one line fix was all I needed to do. ...
    (comp.os.linux.development.system)
  • Re: COBOLs Influence on C
    ... environment that relies on having scads of libraries that must be ... Deployment to production is controlled by a third group: ... Then fix the real problem rather than ranting about how it is everyone ... third party, which calls C from another third party. ...
    (comp.lang.cobol)
  • Re: PDSE Anomaly?
    ... On my production LPAR, I wanted to copy that module over to the product ... I browsed that production load library, and the fix was not on. ... I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not ... see the fix on the load libraries from my production LPAR (still looked good ...
    (bit.listserv.ibm-main)
  • Re: Vista
    ... It's sort of like going back and modifying the "2am fix" to standardize it with the rest of the code. ... Especially dealing with the DRM fixes, it could be that someone left an inefficient tight loop in one of the libraries. ... A man who believes in a God he doesn't see, ...
    (comp.lang.cobol)
  • Re: Simulink crashes in R2007a on linux
    ... Also, looking at those error messages, it looks like libxft1 should ... post on this thread which has a fix for a glibc problem that worked ... font libraries, and that looks like what your error is saying, so ...
    (comp.soft-sys.matlab)