All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>, linux-kernel@vger.kernel.org
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Corey Ashford <cjashfor@linux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	Jean Pihet <jean.pihet@linaro.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCHv2 00/18] perf tools: Factor ordered samples queue
Date: Wed, 18 Jun 2014 13:44:46 -0600	[thread overview]
Message-ID: <53A1EC2E.1010706@gmail.com> (raw)
In-Reply-To: <1403103539-16807-1-git-send-email-jolsa@kernel.org>

On 6/18/14, 8:58 AM, Jiri Olsa wrote:
> hi,
> this patchset factors session's ordered samples queue,
> and allows to limit the size of this queue.
>
> v2 changes:
>    - several small changes for review comments (Namhyung)
>
>
> The report command queues events till any of following
> conditions is reached:
>    - PERF_RECORD_FINISHED_ROUND event is processed
>    - end of the file is reached
>
> Any of above conditions will force the queue to flush some
> events while keeping all allocated memory for next events.
>
> If PERF_RECORD_FINISHED_ROUND is missing the queue will
> allocate memory for every single event in the perf.data.
> This could lead to enormous memory consuption and speed
> degradation of report command for huge perf.data files.
>
> With the quue allocation limit of 100 MB, I've got around
> 15% speedup on reporting of ~10GB perf.data file.
>
> current code:
>   Performance counter stats for './perf.old report --stdio -i perf-test.data' (3 runs):
>
>     621,685,704,665      cycles                    ( +-  0.52% )
>     873,397,467,969      instructions              ( +-  0.00% )
>
>       286.133268732 seconds time elapsed           ( +-  1.13% )
>
> with patches:
>   Performance counter stats for './perf report --stdio -i perf-test.data' (3 runs):
>
>     603,933,987,185      cycles                    ( +-  0.45% )
>     869,139,445,070      instructions              ( +-  0.00% )
>
>       245.337510637 seconds time elapsed           ( +-  0.49% )
>
>
> The speed up seems to be mainly in less cycles spent in servicing
> page faults:
>
> current code:
>       4.44%     0.01%  perf.old  [kernel.kallsyms]   [k] page_fault
>
> with patches:
>       1.45%     0.00%      perf  [kernel.kallsyms]   [k] page_fault
>
> current code (faults event):
>           6,643,807      faults                    ( +-  0.36% )
>
> with patches (faults event):
>           2,214,756      faults                    ( +-  3.03% )
>
>
> Also now we have one of our big memory spender under control
> and the ordered events queue code is put in separated object
> with clear interface ready to be used by another command
> like script.
>
> Also reachable in here:
>    git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>    perf/core_ordered_events
>

I've skimmed through the patches. What happens if you are in the middle 
of a round and the max queue size is reached?

I need to find some time for a detailed review, and to run through some 
stress case scenarios. e.g., a couple that come to mind
perf sched record -- perf bench sched pipe
perf kvm record while booting a nested VM which causes a lot of VMEXITs

David


  parent reply	other threads:[~2014-06-18 19:44 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 14:58 [PATCHv2 00/18] perf tools: Factor ordered samples queue Jiri Olsa
2014-06-18 14:58 ` [PATCH 01/18] perf tools: Always force PERF_RECORD_FINISHED_ROUND event Jiri Olsa
2014-06-18 14:58 ` [PATCH 02/18] perf tools: Fix accounting of ordered samples queue Jiri Olsa
2014-06-18 14:58 ` [PATCH 03/18] perf tools: Rename ordered_samples to ordered_events Jiri Olsa
2014-06-18 14:58 ` [PATCH 04/18] perf tools: Rename ordered_events_queue members Jiri Olsa
2014-06-18 14:58 ` [PATCH 05/18] perf tools: Add ordered_events_(get|put) interface Jiri Olsa
2014-06-27 23:06   ` David Ahern
2014-06-29 16:39     ` Jiri Olsa
2014-06-29 16:50       ` David Ahern
2014-06-30 15:02         ` Arnaldo Carvalho de Melo
2014-06-30 15:03       ` Arnaldo Carvalho de Melo
2014-06-18 14:58 ` [PATCH 06/18] perf tools: Factor ordered_events_flush to be more generic Jiri Olsa
2014-06-18 14:58 ` [PATCH 07/18] perf tools: Limit ordered events queue size Jiri Olsa
2014-06-27 23:11   ` David Ahern
2014-06-30 17:58     ` Jiri Olsa
2014-06-18 14:58 ` [PATCH 08/18] perf tools: Flush ordered events in case of allocation failure Jiri Olsa
2014-06-27 23:07   ` David Ahern
2014-06-29 16:41     ` Jiri Olsa
2014-06-18 14:58 ` [PATCH 09/18] perf tools: Make perf_session_deliver_event global Jiri Olsa
2014-06-18 14:58 ` [PATCH 10/18] perf tools: Create ordered-events object Jiri Olsa
2014-06-18 14:58 ` [PATCH 11/18] perf tools: Use list_move in ordered_event_put function Jiri Olsa
2014-06-18 14:58 ` [PATCH 12/18] perf tools: Add ordered_events_queue_init function Jiri Olsa
2014-06-18 14:58 ` [PATCH 13/18] perf tools: Add ordered_events_queue_free function Jiri Olsa
2014-06-18 14:58 ` [PATCH 14/18] perf tools: Add perf_config_u64 function Jiri Olsa
2014-06-27 23:08   ` David Ahern
2014-06-29 16:44     ` Jiri Olsa
2014-06-18 14:58 ` [PATCH 15/18] perf tools: Add report.queue-size config file option Jiri Olsa
2014-06-18 14:58 ` [PATCH 16/18] perf tools: Add debug prints for ordered events queue Jiri Olsa
2014-06-28  2:52   ` David Ahern
2014-06-29 16:46     ` Jiri Olsa
2014-06-29 16:52       ` David Ahern
2014-06-18 14:58 ` [PATCH 17/18] perf tools: Limit the ordered events queue by default to 100MB Jiri Olsa
2014-06-18 14:58 ` [PATCH 18/18] perf tools: Allow out of order messages in forced flush Jiri Olsa
2014-06-18 19:44 ` David Ahern [this message]
2014-06-19 10:34   ` [PATCHv2 00/18] perf tools: Factor ordered samples queue Jiri Olsa
2014-06-19 17:54     ` David Ahern
2014-06-20  7:15       ` Jiri Olsa

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=53A1EC2E.1010706@gmail.com \
    --to=dsahern@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=jean.pihet@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=paulus@samba.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.