From: Namhyung Kim <namhyung@kernel.org>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: "acme@kernel.org" <acme@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"wangnan0@huawei.com" <wangnan0@huawei.com>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"yao.jin@linux.intel.com" <yao.jin@linux.intel.com>,
"kernel-team@lge.com" <kernel-team@lge.com>
Subject: Re: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done
Date: Tue, 9 Jan 2018 16:12:58 +0900 [thread overview]
Message-ID: <20180109071258.GC7138@sejong> (raw)
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077537FDC1D@SHSMSX103.ccr.corp.intel.com>
Hi,
On Thu, Jan 04, 2018 at 02:00:03PM +0000, Liang, Kan wrote:
> > Hi Kan,
> >
> > On Wed, Jan 03, 2018 at 02:15:38PM +0000, Liang, Kan wrote:
> > > > Hello,
> > > >
> > > > On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.liang@intel.com wrote:
> > > > > From: Kan Liang <kan.liang@intel.com>
> > > > >
> > > > > The direction of overwrite mode is backward. The last
> > mmap__read_event
> > > > > will set tail to map->prev. Need to correct the map->prev to head
> > > > > which is the end of next read.
> > > >
> > > > Why do you update the map->prev needlessly then? I think we don't
> > need it
> > > > for overwrite/backward mode, right?
> > >
> > > The map->prev is needless only when the overwrite does really happen in
> > ringbuffer.
> > > In a light load system or with big ringbuffer, the unprocessed data will not
> > be
> > > overwritten. So it's necessary to keep an pointer to indicate the last
> > position.
> > >
> > > Overwrite mode is backward, but the event processing is always forward.
> > > So map->prev has to be updated in __read_done().
> >
> > Yep, I meant that updating map->prev in every perf_mmap__read_event()
> > is unnecessary for the overwrite mode. It only needs to be set in
> > perf_mmap__read_done(), right?
>
> Right, for overwrite, only updating the map->prev in perf_mmap__read_done()
> is enough.
>
> But for non-overwrite, we have to update map->prev.
> It will be used by perf_mmap__consume() later to write the ring buffer tail.
> So I specially handle the non-overwrite as below in patch 5/12.
Oh I can see it in the patch 5, thanks.
> + event = perf_mmap__read(map, start, end);
> +
> + if (!overwrite)
> + map->prev = *start;
>
> > >
> > > >
> > > > Also I guess the current code might miss some events since the head can
> > be
> > > > different between _read_init() and _read_done(), no?
> > > >
> > >
> > > The overwrite mode requires the ring buffer to be paused during
> > processing.
> > > The head is unchanged between __read_init() and __read_done().
> >
> > Ah, ok then. Maybe we could read the head once, and use it during
> > processing.
>
> Yes, it only needs to read head once for overwrite mode.
> But for non-overwrite, we have to read the head in every
> perf_mmap__read_event(). Because the head is floating.
> The non-overwrite is specially handled in patch 5/12 as well.
Right, I understand it for the non-overwrite mode.
But, for the overwrite mode, my concern was that it might be possible
that it reads a stale head in __read_init() (even after it paused the
ring buffer) and reads an update head in __read_done(). Then it's
gonna miss some records. I'm not sure whether it reads the same head
in __read_init() and __read_done() by the pause.
Thanks,
Namhyung
> + /* non-overwirte doesn't pause the ringbuffer */
> + if (!overwrite)
> + end = perf_mmap__read_head(map);
next prev parent reply other threads:[~2018-01-09 7:13 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 18:08 [PATCH V3 00/12] perf top overwrite mode kan.liang
2017-12-21 18:08 ` [PATCH V3 01/12] perf evlist: remove stale mmap read for backward kan.liang
2017-12-21 18:08 ` [PATCH V3 02/12] perf mmap: factor out function to find ringbuffer position kan.liang
2018-01-10 15:37 ` Jiri Olsa
2018-01-10 19:31 ` Liang, Kan
2018-01-11 14:25 ` Jiri Olsa
2018-01-11 21:26 ` Liang, Kan
2018-01-12 10:52 ` Jiri Olsa
2017-12-21 18:08 ` [PATCH V3 03/12] perf mmap: discard 'prev' in perf_mmap__read kan.liang
2018-01-11 14:25 ` Jiri Olsa
2018-01-11 21:27 ` Liang, Kan
2017-12-21 18:08 ` [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done kan.liang
2018-01-02 7:33 ` Namhyung Kim
2018-01-03 14:15 ` Liang, Kan
2018-01-04 2:46 ` Namhyung Kim
2018-01-04 14:00 ` Liang, Kan
2018-01-09 7:12 ` Namhyung Kim [this message]
2018-01-09 15:12 ` Liang, Kan
2018-01-11 12:00 ` Namhyung Kim
2018-01-11 14:40 ` Liang, Kan
2018-01-11 14:25 ` Jiri Olsa
2018-01-11 21:27 ` Liang, Kan
2017-12-21 18:08 ` [PATCH V3 05/12] perf mmap: introduce perf_mmap__read_event kan.liang
2017-12-21 18:08 ` [PATCH V3 06/12] perf test: update mmap read functions for backward-ring-buffer test kan.liang
2017-12-21 18:08 ` [PATCH V3 07/12] perf mmap: discard legacy interface for mmap read kan.liang
2018-01-11 14:25 ` Jiri Olsa
2018-01-11 21:28 ` Liang, Kan
2018-01-12 10:52 ` Jiri Olsa
2017-12-21 18:08 ` [PATCH V3 08/12] perf top: check per event overwrite term kan.liang
2018-01-11 14:25 ` Jiri Olsa
2018-01-11 21:29 ` Liang, Kan
2018-01-12 11:42 ` Jiri Olsa
2018-01-12 14:58 ` Liang, Kan
2018-01-12 16:46 ` Liang, Kan
2017-12-21 18:08 ` [PATCH V3 09/12] perf evsel: expose perf_missing_features.write_backward kan.liang
2017-12-21 18:08 ` [PATCH V3 10/12] perf top: add overwrite fall back kan.liang
2018-01-11 14:26 ` Jiri Olsa
2018-01-11 21:30 ` Liang, Kan
2018-01-12 11:42 ` Jiri Olsa
2017-12-21 18:08 ` [PATCH V3 11/12] perf top: switch default mode to overwrite mode kan.liang
2018-01-11 14:26 ` Jiri Olsa
2018-01-11 21:30 ` Liang, Kan
2018-01-11 21:30 ` Liang, Kan
2018-01-11 14:26 ` Jiri Olsa
2017-12-21 18:08 ` [PATCH V3 12/12] perf top: check the latency 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=20180109071258.GC7138@sejong \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=wangnan0@huawei.com \
--cc=yao.jin@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox