Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Aug 2014 10:58:42 +0100
From:      David Chisnall <theraven@FreeBSD.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, Adrian Chadd <adrian@freebsd.org>, freebsd-current@freebsd.org, performance@freebsd.org, "current@freebsd.org" <current@freebsd.org>
Subject:   Re: PostgreSQL performance on FreeBSD
Message-ID:  <DD742BF5-09DF-4399-B247-1E36F1CC46F5@FreeBSD.org>
In-Reply-To: <201408121409.40653.jhb@freebsd.org>
References:  <20140627125613.GT93733@kib.kiev.ua> <20140716132938.GB93733@kib.kiev.ua> <CAJ-Vmomfp46GDdWb21g5xi34%2BK-DaCPeyrOHoELOLzRj7-dHrQ@mail.gmail.com> <201408121409.40653.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Aug 2014, at 19:09, John Baldwin <jhb@FreeBSD.org> wrote:

> OTOH, I have actually seen junk profiling _improve_ performance in =
certain=20
> cases as it forces promotion of allocated pages to superpages since =
all pages=20
> are dirtied.  (I have a local hack that adds a new malloc option to =
explicitly=20
> memset() new pages allocated via mmap() that gives the same benefit =
without=20
> the junking overheadon each malloc() / free(), but it does increase =
physical=20
> 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.

David




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DD742BF5-09DF-4399-B247-1E36F1CC46F5>