All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wangnan (F)" <wangnan0@huawei.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: <acme@kernel.org>, <linux-kernel@vger.kernel.org>,
	<pi3orama@163.com>, Adrian Hunter <adrian.hunter@intel.com>,
	He Kuang <hekuang@huawei.com>, Jiri Olsa <jolsa@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>, Zefan Li <lizefan@huawei.com>
Subject: Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot
Date: Mon, 18 Apr 2016 22:37:04 +0800	[thread overview]
Message-ID: <5714F110.2080101@huawei.com> (raw)
In-Reply-To: <20160418142915.GB13675@krava.brq.redhat.com>



On 2016/4/18 22:29, Jiri Olsa wrote:
> On Mon, Apr 18, 2016 at 10:20:23PM +0800, Wangnan (F) wrote:
>>
>> On 2016/4/18 21:45, Jiri Olsa wrote:
>>> On Mon, Apr 18, 2016 at 06:32:08AM +0000, Wang Nan wrote:
>>>> Use 'trigger' to model operations which need to be executed when
>>>> an event (a signal, for example) is observed.
>>>>
>>>> States and transits:
>>>>
>>>>   OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING
>>>>                  ^                    |                      |
>>>>                  |                    |                      |
>>>>                  |                 (ready)                (ready)
>>>>                  |                    |                      |
>>>>                   \__________________/______________________/
>>>>
>>>> is_toggled and is_ready are two key functions to query the state of
>>>> a trigger. is_toggled means the event already happen; is_ready means the
>>>> trigger is waiting for the event.
>>>>
>>>> 'PROCESSING' represents a state the event happens and be observed, and
>>>> the processing is on the way so can't accept a new event immediately.
>>> hum, I must be missing something.. but I dont see how you're
>>> using this state except for smal window within:
>>>
>>>                  if (auxtrace_snapshot_is_toggled()) {
>>>   ->                     auxtrace_snapshot_process();
>>>                          if (!auxtrace_snapshot_is_error())
>>>   ->                              record__read_auxtrace_snapshot(rec);
>>>
>>> but no other place queries or depends on this state
>> Right.
>>
>> Since we are creating a new class, I think we can make code simpler by
>> merging
>> all state variables into trigger.
>>
>> Without this state we must keep 'auxtrace_record__snapshot_started'.
> do we? we dont need this for switch_output code apparently

I think it is a good chance to clean existing code.

However, number of lines introduced to .h in patch 1/6 is more than
lines removed from .c. So I think removing the 'PROCESSING' is okay.
If in future we find switch_output also need this state we can add it
back at that time.

Please wait for v5.

Thank you.

> jirka
>
>> I think merging it into trigger class makes the whole program a little
>> bit simpler. Or do you think keeping trigger class simpler whould be better?
>>
>> Thank you.
>>
>>

  reply	other threads:[~2016-04-18 14:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18  6:32 [PATCH v4 0/6] perf tools: Use SIGUSR2 control data dumpping Wang Nan
2016-04-18  6:32 ` [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot Wang Nan
2016-04-18 13:45   ` Jiri Olsa
2016-04-18 14:20     ` Wangnan (F)
2016-04-18 14:29       ` Jiri Olsa
2016-04-18 14:37         ` Wangnan (F) [this message]
2016-04-18  6:32 ` [PATCH v4 2/6] perf record: Split output into multiple files via '--switch-output' Wang Nan
2016-04-18  6:32 ` [PATCH v4 3/6] perf record: Force enable --timestamp-filename when --switch-output is provided Wang Nan
2016-04-18  6:32 ` [PATCH v4 4/6] perf record: Disable buildid cache options by default in switch output mode Wang Nan
2016-04-18  6:32 ` [PATCH v4 5/6] perf record: Re-synthesize tracking events after output switching Wang Nan
2016-04-18  6:32 ` [PATCH v4 6/6] perf record: Generate tracking events for process forked by perf 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=5714F110.2080101@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=hekuang@huawei.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mhiramat@kernel.org \
    --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 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.