On Thu, Nov 24, 2011 at 09:38:19PM +0400, Maxim Konovalov wrote: > Hi Kostik, > > On Wed, 23 Nov 2011, 11:22+0400, Maxim Konovalov wrote: > > > [...] > > > Anyway, the patch needs testers before I will push it forward. > > > > > [igor's email was corrected] > > > > We will test it in out environment and let you know. > > > It seems I don't understand how it works. > > Here is a test program: http://maxim.int.ru/stuff/malloc_test.c.txt > > It allocates successfully 64x1MB chunks by malloc(), reallocf() and > realloc() with the following command line: > > MALLOC_OPTIONS=JM limits -d 10m ./malloc_test > > When we add L flag to the MALLOC_OPTIONS it starts to work strange: > > It allocates 64MB via malloc() but fails to allocate more than 3MB by > realloc() and reallocf(). The non-failing 64MB allocation is easily explained by a bug. I forgot to account for the case when existing map entry was expanded, instead of new entry created due to mmap(2). The other part, in particular, the failure after 3MB, is in fact the correct behaviour. Jemalloc() caches allocation of the pages, and it allocates more then asked in the request. ktrace(1) shows the whole history. Malloc() first allocated 4MB for the needs of libc etc. Then, it allocated 4MB chunk which was used for satisfying the requests of 1-3MB. When the 4MB request came in, the allocation for 8MB was attempted, and failed, since 4MB (libc etc) + 8MB = 12MB > data limit. > > More funny, the result varies from time to time: I have no explanation for this, and cannot reproduce the issue. Look at the ktrace. Overall, the test is quite curious but absolutely unrealistic. Fixed patch is available at http://people.freebsd.org/~kib/misc/map_datalimit.2.patch
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC