From: Vara Prasad <prasadav@us.ibm.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Paul Mundt <lethal@linux-sh.org>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jes Sorensen <jes@sgi.com>, Andrew Morton <akpm@osdl.org>,
Tom Zanussi <zanussi@us.ibm.com>,
Richard J Moore <richardj_moore@uk.ibm.com>,
Michel Dagenais <michel.dagenais@polymtl.ca>,
Christoph Hellwig <hch@infradead.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
William Cohen <wcohen@redhat.com>,
"Martin J. Bligh" <mbligh@mbligh.org>,
systemtap <systemtap@sourceware.org>
Subject: Re: tracepoint maintainance models
Date: Mon, 18 Sep 2006 19:11:00 -0000 [thread overview]
Message-ID: <450EEF2E.3090302@us.ibm.com> (raw)
In-Reply-To: <1158598927.6069.141.camel@localhost.localdomain>
Alan Cox wrote:
>Ar Llu, 2006-09-18 am 12:15 -0400, ysgrifennodd Frank Ch. Eigler:
>
>
>>>[...] So its L1 misses more register reloads and the like. Sounds
>>>more and more like wasted clock cycles for debug. [...]
>>>
>>>
>>But it's not just "for debug"! It is for system administrators,
>>end-users, developers.
>>
>>
>
>It is for debug. System administrators and developers also do debug,
>they may just use different tools. The percentage of schedule() calls
>executed across every Linux box on the planet where debug is enabled is
>so close to nil its noise. Even with traces that won't change.
>
>
Precisely the reason this huge thread is arguing why we shouldn't be
including only static marker mechanism in the kernel tree. We are using
dynamic probe mechanism which doesn't alter the execution flow or
prevent compiler in making good optimizations for the most part but
there are few code paths that are critical in understanding that we are
not able to use this dynamic method for which we need static markers. As
Martin pointed out if one is critical about performance they can be
compiled out.
It is also important to note the amount of $s lost by taking long time
to find a solution to a problem due to lack of good debugging tools is
also significant compared to few additional clock cycles machines spend
due to these static markers.
>
>
>>Indeed, there will be some non-zero execution-time cost. We must be
>>willing to pay *something* in order to enable this functionality.
>>
>>
>
>There is an implementation which requires no penalty is paid. Create a
>new elf section which contains something like
>
> [address to whack with int3]
> [or info for jprobes to make better use]
> [name for debug tools to find]
> [line number in source to parse the gcc debug data]
>
>
I am not sure i quiet understand your line number part of the proposal.
Does this proposal assume we have access to source code while generating
dynamic probes?
>
>
>
This still doesn't solve the problem of compiler optimizing such that a
variable i would like to read in my probe not being available at the
probe point.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
next parent reply other threads:[~2006-09-18 19:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060917143623.GB15534@elte.hu>
[not found] ` <20060917153633.GA29987@Krystal>
[not found] ` <20060918000703.GA22752@elte.hu>
[not found] ` <450DF28E.3050101@opersys.com>
[not found] ` <20060918011352.GB30835@elte.hu>
[not found] ` <20060918122527.GC3951@redhat.com>
[not found] ` <20060918150231.GA8197@elte.hu>
[not found] ` <1158594491.6069.125.camel@localhost.localdomain>
[not found] ` <20060918152230.GA12631@elte.hu>
[not found] ` <1158596341.6069.130.camel@localhost.localdomain>
[not found] ` <20060918161526.GL3951@redhat.com>
[not found] ` <1158598927.6069.141.camel@localhost.localdomain>
2006-09-18 19:11 ` Vara Prasad [this message]
2006-09-18 19:26 ` Alan Cox
2006-09-18 19:40 ` Frank Ch. Eigler
2006-09-18 20:29 ` Vara Prasad
2006-10-06 5:33 ` Steven Rostedt
2006-10-06 13:03 ` Frank Ch. Eigler
2006-10-06 14:23 ` Steven Rostedt
2006-10-06 23:17 ` Jeremy Fitzhardinge
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=450EEF2E.3090302@us.ibm.com \
--to=prasadav@us.ibm.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=fche@redhat.com \
--cc=gregkh@suse.de \
--cc=hch@infradead.org \
--cc=jes@sgi.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mbligh@mbligh.org \
--cc=michel.dagenais@polymtl.ca \
--cc=mingo@elte.hu \
--cc=richardj_moore@uk.ibm.com \
--cc=systemtap@sourceware.org \
--cc=tglx@linutronix.de \
--cc=wcohen@redhat.com \
--cc=zanussi@us.ibm.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 read-only IMAP folder(s) and NNTP newsgroup(s).