All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 06/15] perf session: load data directory into tool process memory
Date: Wed, 28 Oct 2020 16:22:49 +0900	[thread overview]
Message-ID: <CAM9d7cifhL--aYn05dYABmqoxGXX6xRC9W+Q+cWSnKqGUPPvzA@mail.gmail.com> (raw)
In-Reply-To: <872f5052-788b-fe6d-d0ac-82e9639910d2@linux.intel.com>

On Tue, Oct 27, 2020 at 11:43 PM Alexey Budankov
<alexey.budankov@linux.intel.com> wrote:
>
>
> On 27.10.2020 15:21, Jiri Olsa wrote:
> > On Tue, Oct 27, 2020 at 10:37:58AM +0300, Alexey Budankov wrote:
> >> I agree perf report OOM issue can exist on really-big servers but data
> >> directories support for report mode for not-so-big servers and desktops
> >> is already enabled with this smaller change. Also really-big-servers
> >> come with really-big amount of memory and collection could possibly be
> >> limited to only interesting phases of execution so the issue could likely
> >> be avoided. At the same time threaded trace streaming could clarify on
> >> real use cases that are blocked by perf report OOM issue and that would
> >> clarify on exact required solution. So perf report OOM issue shouldn't
> >> be the showstopper for upstream of threaded trace streaming.
> >
> > so the short answer is no, right? ;-)
>
> Answer to what question? Resolve OOM in perf report for data directories?
> I don't see a simple solution for that. The next issue after OOM is resolved
> is a very long processing of data directories. And again there is no simple
> solution for that as well. But it still need progress in order to be resolved
> eventually.

I think we should find a better way than just adding all events to the
ordered events queue in memory then processing them one by one.

Separating tracking events (FORK/MMAP/...) might be the first step.

Thanks
Namhyung

  reply	other threads:[~2020-10-28 23:26 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21 15:52 [PATCH v2 00/15] Introduce threaded trace streaming for basic perf record operation Alexey Budankov
2020-10-21 15:56 ` [PATCH v2 01/15] perf session: introduce trace file path to be shown in raw trace dump Alexey Budankov
2020-10-22  4:28   ` Namhyung Kim
2020-10-21 15:57 ` [PATCH v2 02/15] perf report: output trace file name " Alexey Budankov
2020-10-22  4:29   ` Namhyung Kim
2020-10-21 15:57 ` [PATCH v2 03/15] perf data: open data directory in read access mode Alexey Budankov
2020-10-22  4:31   ` Namhyung Kim
2020-10-22  7:50     ` Alexey Budankov
2020-10-24 15:43   ` Jiri Olsa
2020-10-26 17:47     ` Alexey Budankov
2020-10-27 11:59       ` Jiri Olsa
2020-10-27 14:44         ` Alexey Budankov
2020-10-21 15:59 ` [PATCH v2 04/15] perf session: move reader object definition to header file Alexey Budankov
2020-10-22  4:31   ` Namhyung Kim
2020-10-24 15:44   ` Jiri Olsa
2020-10-26 17:50     ` Alexey Budankov
2020-10-21 16:00 ` [PATCH v2 05/15] perf session: introduce decompressor into trace reader object Alexey Budankov
2020-10-22  4:36   ` Namhyung Kim
2020-10-22  7:20     ` Alexey Budankov
2020-10-24 15:44   ` Jiri Olsa
2020-10-26  8:54     ` Alexei Budankov
2020-10-21 16:01 ` [PATCH v2 06/15] perf session: load data directory into tool process memory Alexey Budankov
2020-10-24 15:43   ` Jiri Olsa
2020-10-27  7:37     ` Alexey Budankov
2020-10-27 12:21       ` Jiri Olsa
2020-10-27 14:43         ` Alexey Budankov
2020-10-28  7:22           ` Namhyung Kim [this message]
2020-10-28 15:39             ` Jiri Olsa
2020-10-29 11:00               ` Namhyung Kim
2020-10-28 15:36           ` Jiri Olsa
2020-10-27 15:04         ` Alexey Budankov
2020-10-21 16:01 ` [PATCH v2 07/15] perf record: introduce trace file, compressor and stats in mmap object Alexey Budankov
2020-10-21 16:02 ` [PATCH v2 08/15] perf record: write trace data into mmap trace files Alexey Budankov
2020-10-24 15:44   ` Jiri Olsa
2020-10-26  8:52     ` Alexei Budankov
2020-10-26 10:32       ` Jiri Olsa
2020-10-26 14:04         ` Alexei Budankov
2020-10-21 16:03 ` [PATCH v2 09/15] perf record: introduce thread specific objects for trace streaming Alexey Budankov
2020-10-24 15:44   ` Jiri Olsa
2020-10-26  8:53     ` Alexei Budankov
2020-10-21 16:04 ` [PATCH v2 10/15] perf record: manage thread specific data array Alexey Budankov
2020-10-24 15:44   ` Jiri Olsa
2020-10-26  8:39     ` Alexei Budankov
2020-10-21 16:06 ` [PATCH v2 11/15] perf evlist: introduce evlist__ctlfd_update() to update ctl fd status Alexey Budankov
2020-10-21 16:07 ` [PATCH v2 12/15] perf record: introduce thread local variable for trace streaming Alexey Budankov
2020-10-24 15:43   ` Jiri Olsa
2020-10-26  8:21     ` Alexei Budankov
2020-10-26 10:34       ` Jiri Olsa
2020-10-26 14:11         ` Alexei Budankov
2020-10-27 12:01           ` Jiri Olsa
2020-10-27 14:16             ` Alexey Budankov
2020-10-27 15:58             ` Alexey Budankov
2020-10-21 16:08 ` [PATCH v2 13/15] perf record: stop threads in the end of " Alexey Budankov
2020-10-21 16:10 ` [PATCH v2 14/15] perf record: start threads in the beginning " Alexey Budankov
2020-10-24 15:44   ` Jiri Olsa
2020-10-26  8:39     ` Alexei Budankov
2020-10-21 16:10 ` [PATCH v2 15/15] perf record: introduce --threads command line option Alexey Budankov
2020-10-24 15:43 ` [PATCH v2 00/15] Introduce threaded trace streaming for basic perf record operation Jiri Olsa
2020-10-26 17:59   ` Alexey Budankov
2020-10-27 12:10     ` Jiri Olsa
2020-10-27 14:26       ` Alexey Budankov
2020-10-27 16:01       ` Alexey Budankov
2020-10-28  7:08         ` Namhyung Kim
     [not found]           ` <b6150d2f-04a6-9204-59ac-c31c8697c630@linux.intel.com>
2020-10-28 15:32             ` 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=CAM9d7cifhL--aYn05dYABmqoxGXX6xRC9W+Q+cWSnKqGUPPvzA@mail.gmail.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --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.