Date: Wed, 13 Mar 2002 22:50:59 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Greenman <dg@root.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, John Indra <maverick@office.naver.co.id>, freebsd-current@FreeBSD.ORG Subject: Re: malloc() and the stock Perl in -CURRENT (and -STABLE) Message-ID: <3C904853.B89968B4@mindspring.com> References: <20020314104525.B8244@office.naver.co.id> <40628.1016085846@critter.freebsd.dk> <20020313222518.J27616@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > >The above perl program results in a loop more or less like: > > > > n = 2 > > for (i = 0; i < 1000000; i++) > > realloc(n++); > > > >Now, if you read _any_ malloc(3) man page, they will tell you that there > >is no way it can be guaranteed that this does not result in a lot of > >copying. > > Um, except that copying isn't what is causing the problem. The performance > problem is apparantly caused by tens of thousands of page faults per second as > the memory is freed and immediately reallocated again from the kernel. Doesn't > phkmalloc keep a small pool of allocations around to avoid problems like > this? It's the other order, since it has to copy the prior contents... the new memory is malloc'ed, and the old is freed. Poul is right that a remmap() would be useful, in order to move only the mappings, leaving the pages intact, to grow the mmap'ed region and relocate it at the same time. Another thing that's common in most malloc implementations that are less picky than phkmalloc is growth by power-of-2 on each allocation, causing the allocated region to double, after the first realloc, on each grow. The best performance that this will get, though, is the same performance that the per process open file table grow gets (i.e. pretty bad). The remmap is a better idea. It might be wedged into the exiting mmap for a malloc of the same object with a larger size (e.g. remapping MAP_ANON memory with a larger size and a non-zero address implies a zero address, same pages, larger allocation, since mapping over an existing mapping makes no sense). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C904853.B89968B4>