[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100720063805.GA19375@linux.vnet.ibm.com>
Date: Tue, 20 Jul 2010 12:08:05 +0530
From: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
Steven Rostedt <rostedt@...dmis.org>,
Randy Dunlap <rdunlap@...otime.net>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Naren A Devaiah <naren.devaiah@...ibm.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Oleg Nesterov <oleg@...hat.com>,
Mark Wielaard <mjw@...hat.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
LKML <linux-kernel@...r.kernel.org>,
Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@...il.com>,
"Frank Ch. Eigler" <fche@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCHv9 2.6.35-rc4-tip 0/13] Uprobes Patches:
> I tried this again and it worked. That is kinda worked becuase I could
Thanks for trying.
> use it to trace things in my running bash instance, but haven't really
> figured out how to trace something useful using the pid based interface.
> The processes I care about really don't run long enough for that.
I am working/(continue to work) on file based probes. But
currently spending some of my time merging the current patchset to
latest tip. Once this patchset gets pushed to tip, I should be able to
speed up the file based probing.
>
> So thanks for the good work so far, but we'll really need a way to
> define the trace points per-file and have a way to invoke a program
> with tracing that uses it enabled.
>
> A minor note on perf probe -S output: This seems to include a lot of
> T.456 or similar labels, which from my recollection are gcc internal
> things. It would be good to filter those out as they aren't quite
> useful and just fill up the list.
Okay .. will take a look. Offhand I dont know about the T.456
labels, so I will google and see if its possible for us to identify if
its a t.456 label. However if you know how to identify a t456 label
from normal functions, then it would be great.
>
>
> And I really need to complain about the per-patch changelogs inside
> the visible commit message again. I know you disagree, but it's
> a real pain to read through it in git-log when you look for information
> about the patch (which for some of the patches is rather short anyway)
> and all you see is some rather useless patch versioning changelogs.
I am okay with dropping the Changelog or moving the Changelog under the
--- section. However I had retained it because Stephen Rostedt
replied to your post saying he found Changelog to be useful.
Assuming, he is fine dropping the changelog, I will move the
Changelog to the --- section as suggested by you.
> This is what basically all patches to the kernel do, and what's also
> suggested in Documentation/SubmittingPatches.
Agree.
>
> While talking about changelogs: your patches duplicate the patch
> subject line inside the mail body, leading to rather funny git
> commit messages after a git-am:
>
> commit c32a1b63db113bb1508dbf01af34d29f6cda747a
> Author: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> Date: Mon Jul 12 16:04:42 2010 +0530
>
> perf: show functions in a file without using pid
>
> [RFC] perf: show functions in a file without using pid
Okay, I shall drop the Subject from the body of the patch next time I
send the patchset.
--
Thanks and Regards
Srikar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists