This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> Wolfram Gloger writes: Wolfram> Hello, >> looking at a problem with getrlimit/setrlimit, I noticed that malloc >> in glibc 2.2 doesn't work as expected. The appended program gives >> with a glibc 2.1 system: >> >> gromit:/tmp/pr:[0]$ ./rlimit >> rlim_cur 1240, rlim_max: 2147483647 >> malloc returned: (nil) >> >> But the current glibc 2.2 version does: >> $ LD_LIBRARY_PATH=. elf/ld-linux.so.2 /tmp/pr/rlimit >> rlim_cur 1240, rlim_max: 2147483647 >> malloc returned: 0x40117008 Wolfram> I consider this a feature, not a bug :-). The increasing bunch of Wolfram> lucky people with >2GB 32bit systems will probably agree with me, too. Wolfram> All you have done with rlimit is to limit the `classical' heap even Wolfram> further than the `normal' 1GB, so the non-linear heap is now used. Forget the rlimit issues, I've just used them to illustrate a problem I had with malloc. >> Why is glibc 2.2 using mmap and glibc 2.1 not? Wolfram> If sbrk() would fail on 2.1, there could only be n_mmaps_max further Wolfram> allocations. No matter how large we would increase n_mmaps_max, I'm Wolfram> sure someone would complain that her machine still can't allocate all Wolfram> the available memory. Wolfram> So, I changed the meaning of n_mmaps_max to mean the following limit: Wolfram> In 2.1: Wolfram> n_mmaps_max was a hard limit on the number of chunks alocated with Wolfram> mmap(). Beyond the limit, if sbrk() failed, malloc would return 0. Wolfram> In 2.2: Wolfram> Until n_mmaps_max is reached, mmap() is used in preference of sbrk(). Wolfram> When n_mmaps_max is reached or passed, sbrk() is _always_ tried first. Wolfram> However, mmap() is now always tried as a last resort before giving up Wolfram> and returning 0. Wolfram> So, the parameter is still useful for avoiding mmap() on a system Wolfram> where it's very costly (Linux surely isn't such a system), but it Wolfram> doesn't limit the total number of chunks that can be allocated. Do I understand you correctly that you changed the meanings of the environment variables MALLOC_MMAP_THRESHOLD_ and MALLOC_MMAP_MAX_ (and the corresponding mallopt options) in a non compatible way - which violates the documentation? Playing around with MALLOC_MMAP_MAX I noticed that it's impossible to switch off mmap completly. Do you really define this as a "feature" of glibc 2.2? IMO it's a bug. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |