PostgreSQL performance on FreeBSD

Alan Cox alan.l.cox at
Wed Aug 13 16:23:45 UTC 2014

On Wed, Aug 13, 2014 at 4:58 AM, David Chisnall <theraven at>

> On 12 Aug 2014, at 19:09, John Baldwin <jhb at> 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
> explicitly
> > 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?

No.  MAP_PREFAULT_READ does not allocate physical pages.  It establishes
mappings to pages that are already allocated.

> 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.
> David
> _______________________________________________
> freebsd-current at mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at"

More information about the freebsd-current mailing list