realloc+write benchmark

[Radim Kolar]

ten `benchmark` je v ports/benchmarks/forkbomb

> 	Bezpecnost obvykle neco stoji, v tomto pripade trochu vykonu - ale
> jde to vypnout, a defaultni nastaveni je spravne = "bezpecne".
defaultni nastaveni je bez junku. junk je defaultne pouze s
#ifdef MALLOC_EXTRA_SANITY
Zapnuti junku ho jeste vic zbrzdi:
forkbomb -l 32 -i 256 -M --quit  4.03s user 5.72s system 74% cpu 13.019 total
(hsn at ttyv2):~/myports% export MALLOC_OPTIONS=Jr                           20:59
(hsn at ttyv2):~/myports% time forkbomb -l 32 -i 256 -M --quit               21:02
forkbomb -l 32 -i 256 -M --quit  11.54s user 5.89s system 72% cpu 24.205 total

Kdyz ten program odprofilujete, zjistite ze 98% CPU casu se travi
ve funkci memcopy(), coz chapu - malloc neumi zvetsit posledni blok a tak ho
prekopiruje jinam, pricemz stacilo by ho natahnout a to budto pomoci syscall mremap (freebsd nepodporuje, presneji receno podporuje jenom v Linuxove emulaci a to jeste pouze smerem dolu) nebo alespon brk()em. Linux alokuje bloky vetsi
nez jedna stranka mmapem /dev/zero a mremapem jim meni velikost (libc2.3.2)

Zajimava je ale jeste jina vec:

system travi nejak moc kernel casu ve funkci brk() aby zvetsil pamet procesu,
coz je divne protoze brk je tradicne rychly memory alloc syscall. Nekdo tady
prezentoval jiny benchmark (ports/benchmarks/ubench) a bylo videt ze freeBSD5
je pri praci s pameti o dost pomalejsi nez verze 4.