On 12 Aug 2014, at 19:09, John Baldwin <j...@freebsd.org> wrote:
> OTOH, I have actually seen junk profiling _improve_ performance in certain
> cases as it forces promotion of allocated pages to superpages since all pages
> are dirtied. (I have a local hack that adds a new malloc option to
> memset() new pages allocated via mmap() that gives the same benefit without
> the junking overheadon each malloc() / free(), but it does increase physical
> RAM usage.)
Do you get the same effect by adding MAP_ALIGNED_SUPER | MAP_PREFAULT_READ to
the mmap() call in jemalloc? I've been meaning to try the latter on BERI, as
we spend a lot of time bouncing back and forth between user code and the TLB
miss handlers. Given that jemalloc asks for memory in 8MB chunks (I think via
a single mmap call, although I'm not 100% certain), MAP_ALIGNED_SUPER should
have little impact on any platform. MAP_PREFAULT_READ may cause problems on
machines with limited RAM and no swap (I don't know if the VM subsystem knows
that it can safely discard a zero'd page that has been read but not written -
I'd hope so, but it's been a while since I read that code).
It might be that we can make jemalloc autotune whether to use MAP_PREFAULT_READ
depending on some heuristic. I wonder if something as simple as 'turn it on
after the first mmap call' would be enough: programs that don't use more than
8MB of RAM won't prefault, but after that the wasted physical memory becomes an
increasingly small percentage.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"