[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Process address space
>>>>> "WLI" == William Lee Irwin <wli@holomorphy.com> writes:
WLI> On Thu, Jan 10, 2002 at 10:20:24AM +0200, Momchil Velikov wrote:
>> FUD or just plain stupid. He could have solved all the problems he
>> described by just simply linking statically his proggie.
WLI> Well, yes, though there may be some reason it must be dynamically linked.
WLI> "Marvin" == Marvin Justice <mjustice@austin.rr.com> writes:
>>> Anyway, I just wanted to let you know that there are some glibc issues that
>>> are more restrictive than the kernel issues.
Actually, these aren't Marvin's words.
WLI> On Thu, Jan 10, 2002 at 10:20:24AM +0200, Momchil Velikov wrote:
>> FUD. Period. On my system mozilla's (as an example of shlib heavy app)
>> shared libraries occupy (with holes) 0x40000000-0x417bc000 ==
>> 0x17bc000 == 24887296 ~= 23.7 MB. What's the problem allocating
>> libraries at e.g. 0x8000000? Or 0xa0000000?
WLI> Actually, it's an interaction with the kernel. The ELF .interp is loaded
WLI> by default at 0x40000000 when formatted as a DSO. Formatting the .interp
How come ? The kernel just searches for mmap space starting at
TASK_UNMAPPED_BASE == TASK_SIZE / 3. It manages the
[TASK_UNMAPPED_BASE, TASK_SIZE) range by a simple address ordered
first fit algorithm. It just doesn't leave enough space for sbrk,
_for no good reason_. (at least as far as I can tell).
Here's the program headers of /lib/ld-2.2.4.so
LOAD 0x000000 0x00000000 0x00000000 0x13ce0 0x13ce0 R E 0x1000
LOAD 0x013ce0 0x00014ce0 0x00014ce0 0x002f8 0x006f8 RW 0x1000
DYNAMIC 0x013d98 0x00014d98 0x00014d98 0x000b0 0x000b0 RW 0x4
I don't see 0x40000000 here.
WLI> as a statically linked executable will allow you to specify the placement
WLI> in memory (at least in an advisory way) of your runtime linker, if you
WLI> care to implement a runtime linker or adjust glibc's. Alternatively, you
WLI> could have the .interp literally copy itself out of the way and perform
WLI> relocation processing on itself a second time.
WLI> At any rate, probably the core issues here are (as I see them)
WLI> (1) glibc's allocator is unable to deal with a process address space
WLI> fragmented by ld.so sitting up at 0x40000000
Indeed, Doug Lea's malloc slightly predates most mmap based
OSes. However, moving TASK_UNAMPPED_BASE up will solve the problem
with most (non mmap) using programs. The mmap using programs, use
mmap anyway (surprise ;) and are perfectly capable of more inteligent
mmaping, e.g. by specifying a hint as a first parameter to mmap. The
kernel will obey this hint.
WLI> (2) the kernel makes a default placement decision for the .interp that
WLI> fragments the process address space
Not for interp but for any mmap (NULL, ...).
Regards,
-velco
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
IRC Channel: irc.openprojects.net / #kernelnewbies
Web Page: http://www.kernelnewbies.org/