Date: Thu, 14 Mar 2002 15:00:41 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Alfred Perlstein <bright@mu.org>, David Greenman <dg@root.com>, John Indra <maverick@office.naver.co.id>, freebsd-current@FreeBSD.ORG Subject: Re: malloc() and the stock Perl in -CURRENT (and -STABLE) Message-ID: <200203142300.g2EN0f649706@apollo.backplane.com> References: <841.1016099616@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:>Have you thought about issuing a madvise(MADV_WILLNEED) after the
:>brk/mmap call in malloc, at least doing it when it's called via
:>realloc, this might get rid of the superfolous (sp?) page faults
:>that David Greenman reported.
:
:It would be much more valuable to add a
: mremap(void *from, void *to, size_t length);
:
:since that can _solve_ the problem in _all_ cases, rather than
:add more or less byzantine workarounds for silly benchmarks.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:phk@FreeBSD.ORG | TCP/IP since RFC 956
It would have to be something like:
mremap(from, to/NULL, osize, nsize)
We have no information on the original size of the mmap() in the system
because the original vm_map_entry may (A) get cut up by mprotect()
calls and (B) get combined with adjacent vm_map_entry's.
Personally speaking I think code that depends on realloc() to the
extent that mremap() would be necessary is broken code.
-
Also, there are other ways of dealing with this problem. A large
malloc() or realloc() can certainly mmap() more space then it immediately
needs, and then grow into the space (or reuse the extra space for
other purposes if UVM gets tight).
-
MADV_WILLNEED has no effect on pages that are not already in the
VM Page cache. A zero-fill page is not so calling madvise() after
[s]brk() or mmap(...MAP_ANON...) will have no effect. The mmap
manual page describes this in detail.
MADV_FREE can be used in liu of munmap() but phkmalloc does not use
it quite this way, phkmalloc will still free the page when the cache
is blown out.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200203142300.g2EN0f649706>