From: "acme@kernel.org" <acme@kernel.org>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
"Odzioba, Lukasz" <lukasz.odzioba@intel.com>,
"wangnan0@huawei.com" <wangnan0@huawei.com>,
"hekuang@huawei.com" <hekuang@huawei.com>,
"ast@kernel.org" <ast@kernel.org>,
"ak@linux.intel.com" <ak@linux.intel.com>
Subject: Re: [PATCH RFC V4 5/6] perf top: switch to backward overwrite mode
Date: Mon, 2 Oct 2017 15:03:46 -0300 [thread overview]
Message-ID: <20171002180346.GB2869@kernel.org> (raw)
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077537CD661@SHSMSX103.ccr.corp.intel.com>
Em Mon, Oct 02, 2017 at 05:19:41PM +0000, Liang, Kan escreveu:
>
>
> > On Fri, Sep 29, 2017 at 07:47:56AM -0700, kan.liang@intel.com wrote:
> > > From: Kan Liang <kan.liang@intel.com>
> > >
> > > perf_top__mmap_read has severe performance issue in Knights
> > > Landing/Mill, when monitoring in heavy load system. It costs several
> > > minutes to finish, which is unacceptable.
> > >
> > > perf top was overwrite mode. But it is changed to non overwrite mode
> > > since commit 93fc64f14472 ("perf top: Switch to non overwrite mode").
> > > For non overwrite mode, it tries to read everything in the ring buffer
> > > and does not check the messup. Once there are lots of samples
> > > delivered shortly, the processing time could be very long.
> > > Knights Landing/Mill as a manycore processor contains a large number
> > > of small cores. Because of the huge core number, it will generated
> > > lots of samples in a heavy load system. Also, since the huge sample#,
> > > the mmap writer probably bite the tail and mess up the samples.
> > >
> > > Also, to avoid the problems which is described in commit 9ecda41acb97
> > > ("perf/core: Add ::write_backward attribute to perf event"), switch to
> > > backward overwrite mode.
> > > Pausing the ring-buffer during perf_top__mmap_read to ensure the
> > > ring-buffer is stable.
> > > There would be some records lost in backward overwrite mode. Removing
> > > the lost events checking.
> >
> > I'm getting perf top hogging the cpu completely with this change
> >
>
> I think I find the root cause of the cpu hogging.
> perf_mmap__read_catchup discards the md->prev from previous mmap_read.
> Current mmap_read doesn't know which data has already been processed by
> previous mmap_read. So it has to go through all the valid data in the ring buffer,
> even most of the data has been processed by previous mmap_read.
>
> Also, it looks perf record has the similar issue.
> The previous location will be discarded as well in backward overwrite mode.
> That will be an issue when --overwrite and --switch-output are enabled.
> The new output will always include the old data in the previous output, which
> should be wrong.
>
> I think I will rewrite the perf_mmap__read_backward and perf_mmap__read_catchup
> to fix this issue in a separate thread. Those functions should be common backward
> mmap_read functions for all tools and tests.
>
> BTW, are you OK with patch 1-4?
> Those patches multithreading the machine__synthesize_threads, which is
> irrelevant with the overwrite mode.
> I think they can be merged separately.
I'll try and process 1-4 while you work on the read_backward case.
- Arnaldo
next prev parent reply other threads:[~2017-10-02 18:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 14:47 [PATCH RFC V4 0/6] perf top optimization kan.liang
2017-09-29 14:47 ` [PATCH RFC V4 1/6] perf tools: lock to protect namespaces and comm list kan.liang
2017-10-02 18:05 ` Arnaldo Carvalho de Melo
2017-10-02 19:14 ` Liang, Kan
2017-10-02 19:34 ` Arnaldo Carvalho de Melo
2017-10-03 16:44 ` [tip:perf/core] perf tools: Lock " tip-bot for Kan Liang
2017-09-29 14:47 ` [PATCH RFC V4 2/6] perf tools: lock to protect comm_str rb tree kan.liang
2017-10-03 16:45 ` [tip:perf/core] perf tools: Lock " tip-bot for Kan Liang
2017-09-29 14:47 ` [PATCH RFC V4 3/6] perf top: implement multithreading for perf_event__synthesize_threads kan.liang
2017-10-03 16:45 ` [tip:perf/core] perf top: Implement " tip-bot for Kan Liang
2017-09-29 14:47 ` [PATCH RFC V4 4/6] perf top: add option to set the number of thread for event synthesize kan.liang
2017-10-03 16:45 ` [tip:perf/core] perf top: Add " tip-bot for Kan Liang
2017-09-29 14:47 ` [PATCH RFC V4 5/6] perf top: switch to backward overwrite mode kan.liang
2017-09-30 19:48 ` Jiri Olsa
2017-10-02 17:19 ` Liang, Kan
2017-10-02 18:03 ` acme [this message]
2017-10-03 8:24 ` Jiri Olsa
2017-09-29 14:47 ` [PATCH RFC V4 6/6] perf top: check the cost of perf_top__mmap_read kan.liang
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=20171002180346.GB2869@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=ast@kernel.org \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.odzioba@intel.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=wangnan0@huawei.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 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.