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

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to