All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@intel.com>
To: "Wangnan (F)" <wangnan0@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"acme@kernel.org" <acme@kernel.org>,
	"jolsa@redhat.com" <jolsa@redhat.com>,
	"namhyung@kernel.org" <namhyung@kernel.org>
Subject: RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming
Date: Wed, 1 Nov 2017 16:13:43 +0000	[thread overview]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077537DC3B1@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <01f61c50-c176-f9fc-8711-b1308b455bd0@huawei.com>

 > On 2017/11/1 23:04, Liang, Kan wrote:
> >> On 2017/11/1 22:22, Liang, Kan wrote:
> >>>> On 2017/11/1 21:26, Liang, Kan wrote:
> >>>>>> The meaning of perf record's "overwrite" option and many
> "overwrite"
> >>>>>> in source code are not clear. In perf's code, the 'overwrite' has
> >>>>>> 2
> >> meanings:
> >>>>>>     1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument).
> >>>>>>     2. Set evsel's "backward" attribute (in apply_config_terms).
> >>>>>>
> >>>>>> perf record doesn't use meaning 1 at all, but have a overwrite
> >>>>>> option, its real meaning is setting backward.
> >>>>>>
> >>>>> I don't understand here.
> >>>>> 'overwrite' has 2 meanings. perf record only support 1.
> >>>>> It should be a bug, and need to be fixed.
> >>>> Not a bug, but ambiguous.
> >>>>
> >>>> Perf record doesn't need overwrite main channel (we have two
> channels:
> >>>> evlist->mmap is main channel and evlist->backward_mmap is backward
> >>>> evlist->channel),
> >>>> but some testcases require it, and your new patchset may require it.
> >>>> 'perf record --overwrite' doesn't set main channel overwrite. What
> >>>> it does
> >> is
> >>>> moving all evsels to backward channel, and we can move some evsels
> >> back to
> >>>> the main channel by /no-overwrite/ setting. This behavior is hard
> >>>> to understand.
> >>>>
> >>> As my understanding, the 'main channel' should depends on what user
> sets.
> >>> If --overwrite is applied, then evlist->backward_mmap should be the
> >>> 'main channel'. evlist->overwrite should be set to true as well.
> >> Then it introduces a main channel switching mechanism, and we need
> >> checking evlist->overwrite and another factor to determine which one
> >> is the main channel. Make things more complex.
> > We should check the evlist->overwrite.
> > Now, all perf tools force evlist->overwrite = false. I think it doesn’t make
> sense.
> >
> > What is another factor?
> 
> If we support mixed channel as well as forward overwrite ring buffer,
> evlist->overwrite is not enough.

I think you have a detailed analysis regarding to the weakness of 'forward overwrite'.
commit ID 9ecda41acb97 ("perf/core: Add ::write_backward attribute to perf event").

There is no perf tools use 'forward overwrite' mode.

The only users are three perf test cases. We can change them to 'backward overwrite'

I think it's OK to discard the 'forward overwrite' mode

> 
> > I don't think it will be too complex.
> >
> > In perf_evlist__mmap_ex, we just need to add a check.
> > If (!overwrite)
> > 	evlist->mmap = perf_evlist__alloc_mmap(evlist); else
> > 	evlist->backward_mmap = perf_evlist__alloc_mmap(evlist);
> >
> > In perf_evlist__mmap_per_evsel, we already handle per-event overwrite.
> > It just need to add some similar codes to handler per-event nonoverwrite.
> 
> Then the logic becomes:
> 
>   if (check write_backward) {
>      maps = evlist->backward_mmap;
>      if (!maps) {
>        maps = perf_evlist__alloc_mmap(...);
>        if (!maps) {
>            /* error processing */
>        }
>        evlist->backward_mmap = maps;
>        if (evlist->bkw_mmap_state == BKW_MMAP_NOTREADY)
>          perf_evlist__toggle_bkw_mmap(evlist, BKW_MMAP_RUNNING);
>      }
>   } else {
>      maps = evlist->mmap;
>      if (!maps) {
>        maps = perf_evlist__alloc_mmap(...);
>        if (!maps) {
>            /* error processing */
>        }
>        evlist->mmap = maps;
>        ....
>      }
>   }
> 

Thanks.
It looks good to me.

Kan

> > For other codes, they should already check evlist->mmap and evlist-
> >backward_mmap.
> > So they probably don't need to change.
> >
> >
> > Thanks,
> > Kan
> >
> >
> 

      reply	other threads:[~2017-11-01 16:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01  5:53 [PATCH 0/2] perf record: Fix --overwrite and clarify concepts Wang Nan
2017-11-01  5:53 ` [PATCH 1/2] perf mmap: Fix perf backward recording Wang Nan
2017-11-01  9:49   ` Namhyung Kim
2017-11-01 10:32     ` Wangnan (F)
2017-11-01 12:00       ` Namhyung Kim
2017-11-01 12:10         ` Wangnan (F)
2017-11-01 12:39           ` Jiri Olsa
2017-11-01 12:56             ` Wangnan (F)
2017-11-02 15:12               ` Jiri Olsa
2017-11-01 13:57           ` Liang, Kan
2017-11-01 16:12             ` Wangnan (F)
2017-11-01 16:22               ` Liang, Kan
2017-11-02  5:34                 ` Namhyung Kim
2017-11-02 13:25                   ` Liang, Kan
2017-11-02 14:59                     ` Jiri Olsa
2017-11-01  5:53 ` [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming Wang Nan
2017-11-01 10:03   ` Namhyung Kim
2017-11-01 10:17     ` Wangnan (F)
2017-11-01 12:03       ` Namhyung Kim
2017-11-01 13:26   ` Liang, Kan
2017-11-01 14:05     ` Wangnan (F)
2017-11-01 14:22       ` Liang, Kan
2017-11-01 14:44         ` Wangnan (F)
2017-11-01 15:04           ` Liang, Kan
2017-11-01 16:00             ` Wangnan (F)
2017-11-01 16:13               ` Liang, Kan [this message]

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=37D7C6CF3E00A74B8858931C1DB2F077537DC3B1@SHSMSX103.ccr.corp.intel.com \
    --to=kan.liang@intel.com \
    --cc=acme@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.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.