Message-ID: <4510413F.2030200@us.ibm.com>
Date:	Tue, 19 Sep 2006 12:13:03 -0700
From:	Vara Prasad <prasadav@...ibm.com>
To:	Martin Bligh <mbligh@...gle.com>
CC:	prasanna@...ibm.com, Andrew Morton <akpm@...l.org>,
	"Frank Ch. Eigler" <fche@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Paul Mundt <lethal@...ux-sh.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>, ltt-dev@...fik.org,
	systemtap@...rces.redhat.com, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Kernel Markers

Martin Bligh wrote:

> [...]
> Depends what we're trying to fix. I was trying to fix two things:
>
> 1. Flexibility - kprobes seem unable to access all local variables etc
> easily, and go anywhere inside the function. Plus keeping low overhead
> for doing things like keeping counters in a function (see previous
> example I mentioned for counting pages in shrink_list).
>
Using tools like systemtap on can consult DWARF information and put 
probes in the middle of the function and access local variables as well, 
that is not the real problem. The issue here is compiler doesn't seem to 
generate required DWARF information in some cases due to optimizations.  
The other related problem is when there exists debug information, the 
way to specify the breakpoint location is using line number which is not 
maintainable, having a marker solves this problem as well. Your proposal 
still doesn't solve the need for markers if i understood correctly.

> 2. Overhead of the int3, which was allegedly 1000 cycles or so, though
> faster after Ingo had played with it, it's still significant.

The reason Kprobes use breakpoint instruction as pointed out by Prasanna 
is, it is atomic on most platforms. We are already working on an 
improved idea using jump instruction with which overhead is less than 
100 cycles on modern CPU's but it has some limitations and issues 
related to preemption and SMP.

You can get a glimpse of some of the issues here
http://sourceware.org/ml/systemtap/2006-q3/msg00507.html
http://sourceware.org/ml/systemtap/2005-q4/msg00117.html
For more details do a search for djprobe in the systemtap mailing list 
(sorry i am not able to find few threads to summarize all the issues).

Here is the algorithm djprobes uses to

        IA
         | 
[-2][-1][0][1][2][3][4][5][6][7]
        [ins1][ins2][  ins3 ]
        [<-     DCR       ->]
           [<- JTPR ->]

ins1: 1st Instruction
ins2: 2nd Instruction
ins3: 3rd Instruction
IA:  Insertion Address
JTPR: Jump Target Prohibition Region
DCR: Detoured Code Region


The replacement procedure of djpopbes is the following (i have simplified for readability the actual steps djprobes uses)

(1) copying instruction(s) in DCR
(2) putting break point instruction at IA
(3) make sure no cpu's have replacing instructions in the cache to avoid jump to the middle of jmp instruction
(4) replacing original instruction(s) with jump instruction 


As you can see from the above your suggestion is very similar to the 
djprobes hence i believe all the issues related to djprobes will be 
valid for yours as well.

> M.



-
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