From: Masami Hiramatsu <mhiramat@kernel.org>
To: Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: rostedt@goodmis.org, tglx@linutronix.de, namhyung@kernel.org,
vedang.patel@intel.com, bigeasy@linutronix.de,
joel.opensrc@gmail.com, joelaf@google.com,
mathieu.desnoyers@efficios.com, baohong.liu@intel.com,
rajvi.jingar@intel.com, julia@ni.com, fengguang.wu@intel.com,
linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH 3/4] tracing: Add action comparisons when testing matching hist triggers
Date: Thu, 5 Apr 2018 12:50:16 +0900 [thread overview]
Message-ID: <20180405125016.6460a0ab372061ecf49f471a@kernel.org> (raw)
In-Reply-To: <1522855023.32118.14.camel@tzanussi-mobl.amr.corp.intel.com>
On Wed, 04 Apr 2018 10:17:03 -0500
Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> Hi Masami,
>
> On Wed, 2018-04-04 at 21:33 +0900, Masami Hiramatsu wrote:
> > Hi Tom,
> >
> > On Mon, 02 Apr 2018 12:09:33 -0500
> > Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> >
> > > after:
> > >
> > > # echo 'wakeup_latency u64 lat; pid_t pid' >> /sys/kernel/debug/tracing/synthetic_events
> > > # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
> > > # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0 if next_comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> > > # echo 'hist:keys=next_pid:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,next_pid) if next_comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> > > # echo 'hist:keys=next_pid:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,prev_pid) if next_comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> > > # echo 'hist:keys=next_pid if next_comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> >
> > I ensured this sequence has no problem.
> > After above sequence, the trigger file shows
> >
> > ======
> > # cat events/sched/sched_switch/trigger
> > hist:keys=next_pid:vals=hitcount:wakeup_lat=common_timestamp.usecs-$ts0:sort=hitcount:size=2048:clock=global if next_comm=="cyclictest" [active]
> > hist:keys=next_pid:vals=hitcount:sort=hitcount:size=2048:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,next_pid) if next_comm=="cyclictest" [active]
> > hist:keys=next_pid:vals=hitcount:sort=hitcount:size=2048:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,prev_pid) if next_comm=="cyclictest" [active]
> > hist:keys=next_pid:vals=hitcount:sort=hitcount:size=2048 if next_comm=="cyclictest" [active]
> > ======
> >
> > So I clear the last one
> >
> > ======
> > # echo '!hist:keys=next_pid if next_comm=="cyclictest"' >> events/sched/sched_switch/trigger
> > #
> > ======
> >
> > OK, it should be removed. I can not see it anymore on the trigger file.
> >
> > ======
> > # cat events/sched/sched_switch/trigger
> > hist:keys=next_pid:vals=hitcount:wakeup_lat=common_timestamp.usecs-$ts0:sort=hitcount:size=2048:clock=global if next_comm=="cyclictest" [active]
> > hist:keys=next_pid:vals=hitcount:sort=hitcount:size=2048:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,next_pid) if next_comm=="cyclictest" [active]
> > hist:keys=next_pid:vals=hitcount:sort=hitcount:size=2048:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,prev_pid) if next_comm=="cyclictest" [active]
> > ======
> >
> > But when I missed to remove it again, it is accepted (is not an error?)
> >
> > ======
> > # echo '!hist:keys=next_pid if next_comm=="cyclictest"' >> events/sched/sched_switch/trigger
> > #
> > ======
>
> This is consistent with existing behavior, not only for the hist
> triggers but ftrace in general I think e.g.
>
> # echo 'traceoff:1 if nr_rq > 1' >> /sys/kernel/debug/tracing/events/block/block_unplug/trigger
> # echo '!traceoff:1 if nr_rq > 1' >> /sys/kernel/debug/tracing/events/block/block_unplug/trigger
> # echo '!traceoff:1 if nr_rq > 1' >> /sys/kernel/debug/tracing/events/block/block_unplug/trigger
>
> # echo 'try_to_wake_up:enable_event:sched:sched_switch:2' >> set_ftrace_filter
> # echo '!try_to_wake_up:enable_event:sched:sched_switch:2' >> set_ftrace_filter
> # echo '!try_to_wake_up:enable_event:sched:sched_switch:2' >> set_ftrace_filter
>
> Neither produces an error trying to remove an already-removed trigger.
> Or are you thinking about something else?
Hmm, OK, it is ftrace's behavior.
> > Hmm... anyway, let's clear others too.
> >
> > ======
> > # echo '!hist:keys=next_pid:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,next_pid) if next_comm=="cyclictest"' >> events/sched/sched_switch/trigger
> > # echo '!hist:keys=next_pid:onmatch(sched.sched_wakeup).wakeup_latency(sched.sched_switch.$wakeup_lat,prev_pid) if next_comm=="cyclictest"' >> events/sched/sched_switch/trigger
> > # cat events/sched/sched_switch/trigger
> > # Available triggers:
> > # traceon traceoff snapshot stacktrace enable_event disable_event enable_hist disable_hist hist
> > ======
> >
> > OK, it is cleared now.
> >
> > Now I test it again.
> >
> > ======
> > # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"' >> events/sched/sched_wakeup/trigger
> > sh: write error: Invalid argument
> > ======
> >
> > Oops, what's the error?
> >
> > ======
> > # cat events/sched/sched_switch/hist
> >
> > ERROR: Variable already defined: ts0
> > Last command: keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"
> > ======
> >
>
> Hmm, but ts0 is defined on sched_wakeup - you removed the triggers on
> sched_switch, but I didn't see where you removed the sched_wakeup
> trigger defining ts0...
Ah, I confused that the sched_switch and sched_wakeup...
Can you print out the error with which event we should see? e.g.
ERROR: Variable already defined at sched_wakeup: ts0
And this shows the good reason why we should reject removing
unexist trigger (with -ENOENT). If I find I can not remove
'hist:keys=pid:ts0=...' from sched_switch, it helps me to
notice my mistake.
> > Hmm, how can I undef ts0 and test it again?
>
> You should be able to remove the sched_wakeup trigger defining ts0 and
> after doing that test again. At least I was able to:
>
> # echo '!hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"' >>
> events/sched/sched_wakeup/trigger
>
> # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"'
> >> events/sched/sched_wakeup/trigger
OK, anyway this works good to me too.
Tested-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2018-04-05 3:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 20:10 [PATCH 0/4] tracing: A few inter-event bugfixes Tom Zanussi
2018-03-28 20:10 ` [PATCH 1/4] tracing: Fix display of hist trigger expressions containing timestamps Tom Zanussi
2018-03-28 20:10 ` [PATCH 2/4] tracing: Don't add flag strings when displaying variable references Tom Zanussi
2018-03-28 20:10 ` [PATCH 3/4] tracing: Add action comparisons when testing matching hist triggers Tom Zanussi
2018-04-02 15:10 ` Masami Hiramatsu
2018-04-02 17:09 ` Tom Zanussi
2018-04-04 12:33 ` Masami Hiramatsu
2018-04-04 13:01 ` Steven Rostedt
2018-04-04 15:17 ` Tom Zanussi
2018-04-05 3:50 ` Masami Hiramatsu [this message]
2018-04-05 23:34 ` Tom Zanussi
2018-04-06 1:53 ` Masami Hiramatsu
2018-04-06 16:47 ` Tom Zanussi
2018-04-07 12:16 ` Masami Hiramatsu
2018-04-12 15:22 ` Tom Zanussi
2018-03-28 20:10 ` [PATCH 4/4] tracing: Make sure variable string fields are NULL-terminated Tom Zanussi
2018-04-02 15:26 ` [PATCH 0/4] tracing: A few inter-event bugfixes Steven Rostedt
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=20180405125016.6460a0ab372061ecf49f471a@kernel.org \
--to=mhiramat@kernel.org \
--cc=baohong.liu@intel.com \
--cc=bigeasy@linutronix.de \
--cc=fengguang.wu@intel.com \
--cc=joel.opensrc@gmail.com \
--cc=joelaf@google.com \
--cc=julia@ni.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=namhyung@kernel.org \
--cc=rajvi.jingar@intel.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tom.zanussi@linux.intel.com \
--cc=vedang.patel@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;
as well as URLs for NNTP newsgroup(s).