kern/61691: very bad performance of realloc()/brk()

Radim Kolar hsn at netmag.cz
Fri Jan 23 12:51:20 PST 2004


The following reply was made to PR kern/61691; it has been noted by GNATS.

From: Radim Kolar <hsn at netmag.cz>
To: Poul-Henning Kamp <phk at FreeBSD.org>
Cc: freebsd-bugs at FreeBSD.org, bug-followup at freebsd.org
Subject: Re: kern/61691: very bad performance of realloc()/brk()
Date: Fri, 23 Jan 2004 16:20:35 +0100

 > You seem to be confused as to what responsibilities the programmer
 > has when it comes to practicing sensible memory management.
 I have run some benchmarks for you. There are doing 32 times realloc() in
 1 MB chunks. I don't think that this is example of bad programming
 practice. The major problem is that realloc() copies data while Linux
 doesn't.
 
 FreeBSD 5.2
 ===========
 It looks that brk() syscall is quite slow in FreeBSD when comparing
 against Linux. FreeBSD calls 32 times brk() and 10 times mmap+munmap (for page directory).
 
 (hsn at ttyv0):~/forkbomb% time ./forkbomb -l 32 -i 256 -M --quit            12:45
 Safety alarm at 300 sec. enabled.
 Actions: alloc 32 MB (step 1024 kB) and touch it.
 Forkbomb 1.2 started.
 ./forkbomb -l 32 -i 256 -M --quit  4.58s user 5.28s system 74% cpu 13.159 total
 
 linux2.4+glibc2.3.2
 ===================
 Linux does 1 times mmap + 31 times mremap syscall
 
 Safety alarm at 300 sec. enabled.
 Actions: alloc 32 MB (step 1024 kB) and touch it.
 Forkbomb 1.2 started.
 ./forkbomb -l 32 -i 256 -M --quit  0.00s user 0.30s system 107% cpu 0.280 total
 
 Well my pr-report/wish is: optimize realloc() function (which is about 3 pages
 long) to avoid copying data while brk() is sufficient , because the reallocated block is
 last block. 


More information about the freebsd-bugs mailing list