linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Seiji Aguchi <saguchi@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Subject: Re: [GIT PULL] tracing: make signal tracepoints more useful
Date: Mon, 16 Jan 2012 16:03:07 +0100	[thread overview]
Message-ID: <20120116150307.GA12817@redhat.com> (raw)
In-Reply-To: <20120116074540.GE15641@elte.hu>

On 01/16, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > > 2/2 looks like a bugfix to me, but 1/2 changes the output from
> > > trace_signal_generate() and removes trace_signal_overflow_fail.
> > > In essence the change is:
> > >
> > > 	-       TP_printk("sig=%d errno=%d code=%d comm=%s pid=%d",
> > > 	+       TP_printk("sig=%d errno=%d code=%d comm=%s pid=%d grp=%d res=%d",
> > >
>
> I've also Cc:-ed Masami-san who appears to have introduced most
> of this trace information.

Thanks... although he is already cc'ed, may be I used the wrong
email.

> Looks good to me at a first (quick) sight, except this bit
> which changes the ABI:
>
> > > 	-       TP_printk("sig=%d errno=%d code=%d comm=%s pid=%d",
> > > 	+       TP_printk("sig=%d errno=%d code=%d comm=%s pid=%d grp=%d res=%d",
>
> That's not how we change tracepoints generally - we add a new
> one and eventually phase out the old one.

Well, "vmscan/trace: Add 'file' info to trace_mm_vmscan_lru_isolate()"
ea4d349f adds the new field too. In fact this patch (floating in -mm)
plus the previous discussion convinced me we should go this way.

> Which apps/tools rely
> on the old tracepoint? If it's exactly zero apps then we might
> be able to change it, but this needs to be investigated.

If only I knew. How can we investigate this? Hopefully nothing
relies on the old tracepoint, but who knows.

OK. So we should add the new tracepoint. Looks a bit ugly, but
I understand your concerns.


Say, trace_send_signal(sig, info, t, group, result), OK?


Seiji, please double check this is all you need, it won't be
simply to change this tracepoint again. While we are adding the
new one, we can add/change something in TP_STRUCT__entry if you
think this is needed.

> Note, it might make sense to send these as two patches to lkml
> with me Cc:-ed to avoid any github trust issues, i can apply
> them and push them to Linus.

Ingo, I sent them 3 times and you were cc'ed ;)

Thanks!

Oleg.


  parent reply	other threads:[~2012-01-16 15:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10 17:45 [PATCH 0/2] tracing: make signal tracepoints more useful Oleg Nesterov
2012-01-10 17:45 ` [PATCH 1/2] tracing: let trace_signal_generate() report more info, kill overflow_fail/lose_info Oleg Nesterov
2012-01-10 17:45 ` [PATCH 2/2] tracing: send_sigqueue() needs trace_signal_generate() too Oleg Nesterov
2012-01-10 18:59 ` [PATCH 0/2] tracing: make signal tracepoints more useful Steven Rostedt
2012-01-10 21:09 ` Seiji Aguchi
2012-01-13 18:20 ` [GIT PULL] " Oleg Nesterov
2012-01-15 18:24   ` Oleg Nesterov
2012-01-16  7:45     ` Ingo Molnar
2012-01-16 12:31       ` Steven Rostedt
2012-01-16 12:53         ` Ingo Molnar
2012-01-16 15:10           ` Oleg Nesterov
2012-01-17 18:50             ` Linus Torvalds
2012-01-18  9:39               ` Ingo Molnar
2012-01-16 15:52           ` Steven Rostedt
2012-01-17 10:02             ` Ingo Molnar
2012-01-17 12:03               ` Steven Rostedt
2012-01-17 12:40                 ` Ingo Molnar
2012-01-17 14:04                   ` Oleg Nesterov
2012-01-18 11:59                     ` Ingo Molnar
2012-01-17 14:37                   ` Steven Rostedt
2012-01-17 14:55                     ` Oleg Nesterov
2012-01-20 18:01                     ` Jason Baron
2012-01-17 19:52               ` Steven Rostedt
2012-01-16 15:03       ` Oleg Nesterov [this message]
2012-01-16 15:42         ` Seiji Aguchi
2012-01-16 15:58         ` Steven Rostedt
2012-01-26 10:10   ` Ingo Molnar

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=20120116150307.GA12817@redhat.com \
    --to=oleg@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=saguchi@redhat.com \
    --cc=torvalds@linux-foundation.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).