From: "Wangnan (F)" <wangnan0@huawei.com>
To: <kan.liang@intel.com>, <acme@kernel.org>, <peterz@infradead.org>,
<mingo@redhat.com>, <linux-kernel@vger.kernel.org>
Cc: <jolsa@kernel.org>, <hekuang@huawei.com>, <namhyung@kernel.org>,
<alexander.shishkin@linux.intel.com>, <adrian.hunter@intel.com>,
<ak@linux.intel.com>
Subject: Re: [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode
Date: Wed, 11 Oct 2017 02:23:54 +0800 [thread overview]
Message-ID: <37b6527e-cc03-db99-e30f-4652c06b5cb0@huawei.com> (raw)
In-Reply-To: <1507656023-177125-3-git-send-email-kan.liang@intel.com>
On 2017/10/11 1:20, kan.liang@intel.com wrote:
> From: Kan Liang <kan.liang@intel.com>
>
> Perf record can switch output. The new output should only store the data
> after switching. However, in overwrite backward mode, the new output
> still have the data from old output.
>
> At the end of mmap_read, the position of processed ring buffer is saved
> in md->prev. Next mmap_read should be end in md->prev.
> However, the md->prev is discarded. So next mmap_read has to process
> whole valid ring buffer, which definitely include the old processed
> data.
>
> Set the prev as the end of the range in backward mode.
>
> Signed-off-by: Kan Liang <kan.liang@intel.com>
> ---
> tools/perf/util/evlist.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 33b8837..7d23cf5 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -742,13 +742,25 @@ static int
> rb_find_range(void *data, int mask, u64 head, u64 old,
> u64 *start, u64 *end, bool backward)
> {
> + int ret;
> +
> if (!backward) {
> *start = old;
> *end = head;
> return 0;
> }
>
> - return backward_rb_find_range(data, mask, head, start, end);
> + ret = backward_rb_find_range(data, mask, head, start, end);
> +
> + /*
> + * The start and end from backward_rb_find_range is the range for all
> + * valid data in ring buffer.
> + * However, part of the data is processed previously.
> + * Reset the end to drop the processed data
> + */
> + *end = old;
> +
I don't understand this patch. What rb_find_range() wants to do is to
find start
and end pointer, so record__mmap_read() knows where to start reading and
where to stop.
In backward mode, 'start' pointer is clearly 'head' (because 'head' is
the header of the
last record kernel writes to the ring buffer), but the 'end' pointer is
not very easy to
find ('end' pointer is the last (the earliest) available record in the
ring buffer).
We have to parse the whole ring buffer to find the last available record
and set its
tail into 'end', this is what backward_rb_find_range() tries hard to do.
However,
your patch unconditionally overwrites *end (which is set by
backward_rb_find_range()),
makes backward_rb_find_range() meaningless.
In my mind when you decide to use backward ring buffer you must make it
overwrite
because you want the kernel silently overwrite old records without
waking up perf, while
still able to parse the ring buffer even if overwriting happens. The use
case
should be: perf runs in background, kernel silently ignores old records
in the ring
buffer until something bad happens, then perf dumps 'events before the
bad thing'.
Similar to fight recorder. In this use case, each dumping is
independent. Even
if one record is appears in previous dumping, it is harmless (and
useful) to make
it appears in following dumping again.
If you really want to avoid record duplication, you need to changes
record__mmap_read()'s
logic. Now it complains "failed to keep up with mmap data" and avoid
dumping data when
size of newly generated data is larger than the size of the ring buffer.
It is reasonable
for forward ring buffer because in this case you lost the head of the
first record, the
whole ring buffer is unparseable. However, it is wrong in backward case.
What you
should do in this case is dumping the whole ring buffer.
> + return ret;
> }
>
> /*
next prev parent reply other threads:[~2017-10-10 18:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-10 17:20 [PATCH 00/10] new mmap_read interfaces for ring buffer kan.liang
2017-10-10 17:20 ` [PATCH 01/10] perf record: new interfaces to read ring buffer to file kan.liang
2017-10-10 18:24 ` Arnaldo Carvalho de Melo
2017-10-10 18:30 ` Arnaldo Carvalho de Melo
2017-10-11 4:12 ` Liang, Kan
2017-10-11 14:45 ` Arnaldo Carvalho de Melo
2017-10-11 15:16 ` Liang, Kan
2017-10-10 17:20 ` [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode kan.liang
2017-10-10 18:14 ` Arnaldo Carvalho de Melo
2017-10-10 18:18 ` Liang, Kan
2017-10-13 12:55 ` Liang, Kan
2017-10-13 13:13 ` Arnaldo Carvalho de Melo
2017-10-13 13:14 ` Liang, Kan
2017-10-10 18:23 ` Wangnan (F) [this message]
2017-10-10 18:50 ` Wangnan (F)
2017-10-10 19:50 ` Liang, Kan
2017-10-10 20:18 ` Wangnan (F)
2017-10-11 2:12 ` Liang, Kan
2017-10-11 14:57 ` Liang, Kan
2017-10-12 1:11 ` Wangnan (F)
2017-10-12 12:49 ` Liang, Kan
2017-10-12 14:43 ` Wangnan (F)
2017-10-10 19:36 ` Liang, Kan
2017-10-10 17:20 ` [PATCH 03/10] perf tool: new iterfaces to read event from ring buffer kan.liang
2017-10-10 18:15 ` Arnaldo Carvalho de Melo
2017-10-10 18:28 ` Liang, Kan
2017-10-10 18:34 ` Arnaldo Carvalho de Melo
2017-10-10 18:36 ` Arnaldo Carvalho de Melo
2017-10-10 19:00 ` Arnaldo Carvalho de Melo
2017-10-10 19:10 ` Wangnan (F)
2017-10-10 19:17 ` Arnaldo Carvalho de Melo
2017-10-10 19:22 ` Wangnan (F)
2017-10-10 19:55 ` Liang, Kan
2017-10-10 19:59 ` Wangnan (F)
2017-10-10 17:20 ` [PATCH 04/10] perf tool: perf_mmap__read_init wrapper for evlist kan.liang
2017-10-10 17:20 ` [PATCH 05/10] perf top: apply new mmap_read interfaces kan.liang
2017-10-10 17:20 ` [PATCH 06/10] perf trace: " kan.liang
2017-10-10 17:20 ` [PATCH 07/10] perf kvm: " kan.liang
2017-10-10 17:20 ` [PATCH 08/10] perf python: " kan.liang
2017-10-10 17:20 ` [PATCH 09/10] perf tests: " kan.liang
2017-10-10 17:20 ` [PATCH 10/10] perf tool: remove stale " 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=37b6527e-cc03-db99-e30f-4652c06b5cb0@huawei.com \
--to=wangnan0@huawei.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome