public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Wangnan (F)" <wangnan0@huawei.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: <arnaldo.melo@gmail.com>, <linux-kernel@vger.kernel.org>,
	He Kuang <hekuang@huawei.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Namhyung Kim <namhyung@kernel.org>, Zefan Li <lizefan@huawei.com>,
	<pi3orama@163.com>
Subject: Re: [PATCH 02/17] perf tools: Add evlist channel helpers
Date: Wed, 18 May 2016 11:27:43 +0800	[thread overview]
Message-ID: <573BE12F.5020603@huawei.com> (raw)
In-Reply-To: <20160513130516.GH11346@kernel.org>



On 2016/5/13 21:05, Arnaldo Carvalho de Melo wrote:
> Em Fri, May 13, 2016 at 07:55:59AM +0000, Wang Nan escreveu:
>> In this commit sereval helpers are introduced to support the principle
>                   several
>
>> of channel. Channels hold different groups of evsels which configured
>> differently. It will be used for overwritable evsels, which allows perf
> why not use multiple evlists? An "evlist" is a "list of evsels", why do
> we need yet another way of grouping evlists?
>
> - Arnaldo
>

There's an assumption all over perf that there's only one evlist: in 
'struct record'
there's an 'evlist' pointer, in 'struct session' there's also an 
'evlist' pointer.
Trying to change them to an array results in 181 errors, so I think 
fundamentally
moving to multiple evlists is nearly impossible.

Now I'm thinking introducing auxiliary evlists to perf record. We still 
obey one
evlist assumption, only creates separated evlists for mmap.

Thank you.

  reply	other threads:[~2016-05-18  3:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13  7:55 [PATCH 00/17] perf tools: Support overwritable ring buffer Wang Nan
2016-05-13  7:55 ` [PATCH 01/17] perf tools: Extract __perf_evlist__mmap_read() Wang Nan
2016-05-13 13:03   ` Arnaldo Carvalho de Melo
2016-05-13  7:55 ` [PATCH 02/17] perf tools: Add evlist channel helpers Wang Nan
2016-05-13 13:05   ` Arnaldo Carvalho de Melo
2016-05-18  3:27     ` Wangnan (F) [this message]
2016-05-18 13:23       ` Arnaldo Carvalho de Melo
2016-05-13  7:56 ` [PATCH 03/17] perf tools: Automatically add new channel according to evlist Wang Nan
2016-05-13  7:56 ` [PATCH 04/17] perf tools: Operate multiple channels Wang Nan
2016-05-13  7:56 ` [PATCH 05/17] perf record: Prevent reading invalid data in record__mmap_read Wang Nan
2016-05-13  7:56 ` [PATCH 06/17] perf tools: Squash overwrite setting into channel Wang Nan
2016-05-13  7:56 ` [PATCH 07/17] perf record: Don't read from and poll overwrite channel Wang Nan
2016-05-13  7:56 ` [PATCH 08/17] perf record: Don't poll on " Wang Nan
2016-05-13 13:12   ` Arnaldo Carvalho de Melo
2016-05-16  3:18     ` Wangnan (F)
2016-05-13  7:56 ` [PATCH 09/17] perf tools: Detect avalibility of write_backward Wang Nan
2016-05-13 13:08   ` Arnaldo Carvalho de Melo
2016-05-20 15:31     ` Wangnan (F)
2016-05-20 15:39       ` Arnaldo Carvalho de Melo
2016-05-13  7:56 ` [PATCH 10/17] perf tools: Enable overwrite settings Wang Nan
2016-05-16 13:38   ` Arnaldo Carvalho de Melo
2016-05-13  7:56 ` [PATCH 11/17] perf tools: Set write_backward attribut bit for overwrite events Wang Nan
2016-05-13  7:56 ` [PATCH 12/17] perf tools: Record fd into perf_mmap Wang Nan
2016-05-13  7:56 ` [PATCH 13/17] perf tools: Add API to pause a channel Wang Nan
2016-05-13  7:56 ` [PATCH 14/17] perf record: Rename variable to make code clear Wang Nan
2016-05-13  7:56 ` [PATCH 15/17] perf record: Read from backward ring buffer Wang Nan
2016-05-13  7:56 ` [PATCH 16/17] perf record: Toggle overwrite ring buffer for reading Wang Nan
2016-05-13  7:56 ` [PATCH 17/17] perf tools: Don't warn about out of order event if write_backward is used Wang Nan

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=573BE12F.5020603@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=hekuang@huawei.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=namhyung@kernel.org \
    --cc=pi3orama@163.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