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