From: Adrian Hunter <adrian.hunter@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: ye olde task_ctx_sched_out trace.
Date: Thu, 22 May 2014 10:10:04 +0300 [thread overview]
Message-ID: <537DA2CC.10306@intel.com> (raw)
In-Reply-To: <20140522070414.GN30445@twins.programming.kicks-ass.net>
On 05/22/2014 10:04 AM, Peter Zijlstra wrote:
> On Thu, May 22, 2014 at 09:52:46AM +0300, Adrian Hunter wrote:
>>> diff --git a/fs/exec.c b/fs/exec.c
>>> index 476f3ebf437e..8d51d7ce3dcf 100644
>>> --- a/fs/exec.c
>>> +++ b/fs/exec.c
>>> @@ -1111,6 +1111,7 @@ void setup_new_exec(struct linux_binprm * bprm)
>>> set_dumpable(current->mm, suid_dumpable);
>>>
>>> set_task_comm(current, kbasename(bprm->filename));
>>> + perf_event_exec();
>>
>> Shouldn't that be the other way around i.e.
>>
>> + perf_event_exec();
>> set_task_comm(current, kbasename(bprm->filename));
>
> I suppose so indeed.
>
>> Also what about flagging the comm event that corresponds to an exec e.g.
>
> I think it was a mistake to conflate the two concepts, and separating
> them into different functions makes things clearer.
My patch was not related to that. It was to get effectively an "exec"
event, by piggybacking the comm event.
next prev parent reply other threads:[~2014-05-22 7:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 15:06 ye olde task_ctx_sched_out trace Dave Jones
2014-05-21 15:16 ` Peter Zijlstra
2014-05-21 15:30 ` Peter Zijlstra
2014-05-21 15:32 ` Peter Zijlstra
2014-05-22 6:52 ` Adrian Hunter
2014-05-22 7:04 ` Peter Zijlstra
2014-05-22 7:10 ` Adrian Hunter [this message]
2014-05-22 7:20 ` Peter Zijlstra
2014-05-22 7:22 ` Peter Zijlstra
2014-05-28 8:02 ` Adrian Hunter
2014-06-06 12:19 ` [tip:perf/core] perf: Differentiate exec() and non-exec() comm events tip-bot for Adrian Hunter
2014-06-06 12:19 ` [tip:perf/core] perf: Fix perf_event_comm() vs. exec() assumption tip-bot for Peter Zijlstra
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=537DA2CC.10306@intel.com \
--to=adrian.hunter@intel.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/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).