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