:>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
:[EMAIL PROTECTED]         | 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.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to