From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Valerie Henson <val@vahconsulting.com>
Cc: opensource@google.com, Jakub Jelinek <jakub@redhat.com>,
linux-mm@kvack.org,
"Rodrigo Rubira Branco (BSDaemon)" <rodrigo@kernelhacking.com>
Subject: Re: ebizzy performance with different allocators
Date: Tue, 25 Mar 2008 16:36:51 +1100 [thread overview]
Message-ID: <200803251636.51474.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <70b6f0bf0803171919t9ba6cbewbc03c9ddae63c255@mail.gmail.com>
On Tuesday 18 March 2008 13:19, Valerie Henson wrote:
> [Cc'd current ebizzy maintainer, Rodrigo.]
>
> On Mon, Mar 17, 2008 at 5:21 AM, Nick Piggin <nickpiggin@yahoo.com.au>
wrote:
> > Hi,
> >
> > I was recently interested in ebizzy performance, and specifically the
> > reason why Linux doesn't appear to scale very well versus FreeBSD.
>
> [snip]
>
> > linux-glibc was the best single-threaded performer, with ~7000 r/s,
> > however it starts running into system time which the profile shows up
> > as unmapping pages and faulting in new pages. Is "fixing" this as simple
> > as increasing hysteresis in glibc? Can that be done via environment? (I
> > couldn't work out a way).
>
> Huh, yeah, that sounds like glibc is mmap()'ing your allocations.
> Check to see if your glibc version includes this patch:
>
> http://www.valhenson.org/patches/dynamic_mmap_threshold
Yes AFAIKS it does (went into glibc 2.5 I think?)
> If it does, you shouldn't see much in the way of mmap/munmap activity
> when running ebizzy. It's possible that some other malloc() settings
> are interfering, maybe the trim threshold. It's also worth noting
> that the self-tuning mmap threshold is disabled if the user sets the
> mmap threshold explicitly.
I didn't set any options.
Hmm, I see from the strace that mmap actually shouldn't be a problem. It
is just a high rate of madvise causing TLB shootdown IPIs I think. Which
means that jemalloc is probably not freeing memory back to the OS as
aggressively as glibc...
I guess glibc could keep around a few more free pages and free them in
batches to reduce this. We could provide some kind of vectored madvise
or munmap if this proves to be really beneficial.
FWIW, glibc malloc performs better than my jemalloc port on that
pathalogical MySQL workload...
> Oh, and is this 32-bit or 64-bit?
64.
> If you want to tune the exact behavior of malloc with regard to mmap, check
> out:
>
> http://www.gnu.org/software/libtool/manual/libc/Malloc-Tunable-Parameters.h
>tml
>
> If you use the "-M" option to ebizzy, it will use mallopt() to turn
> off mmap()'d allocations entirely. (It'd be nice to have command line
> knobs for all the mallopt() tuning options, actually.)
Thanks for the help,
Nick
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-03-25 5:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200803172321.31572.nickpiggin@yahoo.com.au>
2008-03-18 2:19 ` Valerie Henson
2008-03-25 5:36 ` Nick Piggin [this message]
2008-03-18 1:58 Rodrigo Rubira Branco (BSDaemon)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200803251636.51474.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=jakub@redhat.com \
--cc=linux-mm@kvack.org \
--cc=opensource@google.com \
--cc=rodrigo@kernelhacking.com \
--cc=val@vahconsulting.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox