From: David Ahern <dsahern@gmail.com>
To: Ingo Molnar <mingo@kernel.org>, Namhyung Kim <namhyung@kernel.org>
Cc: acme@ghostprotocols.net, linux-kernel@vger.kernel.org,
Frederic Weisbecker <fweisbec@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Olsa <jolsa@redhat.com>, Mike Galbraith <efault@gmx.de>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] perf record: mmap output file - v2
Date: Tue, 15 Oct 2013 07:45:55 -0600 [thread overview]
Message-ID: <525D4713.3060706@gmail.com> (raw)
In-Reply-To: <20131015074451.GA28186@gmail.com>
On 10/15/13 1:44 AM, Ingo Molnar wrote:
>
> * Namhyung Kim <namhyung@kernel.org> wrote:
>
>> [SNIP]
>>> +/* mmap file big chunks at a time */
>>> +#define MMAP_OUTPUT_SIZE (64*1024*1024)
>>
>> Why did you choose 64MB for the size? Did you also test other sizes?
>
> Btw., should this value go up if the ring buffer (mmap_pages) is larger
> than 64MB?
>
I made mmap_size a variable:
+ size_t mmap_size; /* size of mmap segments */
with the above initial value. I was planning to make it in an option and
just forgot to complete it.
Why 64M? mmap / munmap are also system calls and I was looking to trade
off huge file size jumps versus the frequency of adjusting the maps. 64M
Was just a nice round number between 1 and 100. 8, 16 are too small. 128
seems to big for a default. That left only 32 and 64. 64M seems the
better trade off of the two.
Making it a user knob would help with smaller deployments. Could also
have mmap_size = 0 mean turn it off (use write over mmap).
Perhaps something that adjust automatically would be useful too. e.g.,
For the case that motivates the change I have 16 cpus each with a 4M
buffer (1024 mmap pages). Should we generically set the size:
mmap_size = ncpus_online * mmap_pages * page_size?
Do that only for system wide profiling?
David
next prev parent reply other threads:[~2013-10-15 13:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-15 2:55 [PATCH] perf record: mmap output file - v2 David Ahern
2013-10-15 6:02 ` Ingo Molnar
2013-10-15 7:09 ` Namhyung Kim
2013-10-15 7:25 ` Ingo Molnar
2013-10-15 8:17 ` Namhyung Kim
2013-10-15 12:22 ` Jiri Olsa
2013-10-15 13:20 ` Ingo Molnar
2013-10-15 13:25 ` David Ahern
2013-10-16 1:24 ` Namhyung Kim
2013-10-15 7:31 ` Namhyung Kim
2013-10-15 7:44 ` Ingo Molnar
2013-10-15 13:45 ` David Ahern [this message]
2013-10-15 13:35 ` David Ahern
2013-10-16 1:52 ` Namhyung Kim
2013-10-16 1:58 ` David Ahern
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=525D4713.3060706@gmail.com \
--to=dsahern@gmail.com \
--cc=acme@ghostprotocols.net \
--cc=efault@gmx.de \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.