Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes(un)registration and exception handling.

[Srikar Dronamraju]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> [2010-09-06 20:15:22]:

> On Mon, 2010-09-06 at 23:16 +0530, Srikar Dronamraju wrote:
> > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> [2010-09-03 19:19:09]:
> > 
> > > > 
> > > > However I would have an issue with making inode based probing the
> > > > default.
> > > > 1. Making all probing based on inode can be a performance hog.
> > > 
> > > How so? You can add filters if you want.
> > 
> > The breakpoint exception and singlestep account for a substaintial
> > time
> > of the uprobes probe handling. With increasing number of breakpoint
> > hits and singlesteps, wouldnt the overall load increase?
> > 
> You're really not getting it, are you? No, it would result in the exact
> same amount of actual breakpoints hit.

If there is just one instance of traced process for the inode then yes the
number of breakpoints when traced with pid or based on inode would be the
same. However if there are multiple instances of the traced process [example
bash/zsh] (or the inode corresponds to a library that gets mapped into
multiple processes example libc), and the user is interested in tracing
just one instance of the process, then dont wont the inode based tracing
amount to far more number of breakpoints hits?

> 
> > > 
> > > > 2. Since unlike kernel space, every process has a different space, so
> > > > why would we have to insert breakpoints in each of its process space if
> > > > we are not interested in them.
> > > 
> > > You don't have to, but you can. The problem I have with this stuff is
> > > that it makes the pid thing a primary interface, whereas it should be
> > > one of many filter possibilities.
> > 
> > I think the otherway, 
> > Why instrument a process and filter it out, if we are not interested in it.
> > While instrumenting kernel, we dont have this flexibility. So
> > having a pid based filter is the right thing to do for kernel
> > based tracing.
> > 
> > If we can get the per process based tracing right, we can build
> > higher lever stuff including the file based tracing easily.
> 
> Creating inode based probes on top of pid based probes is terribly ugly.

I would disagree. 
Lets consider a user wants to trace his single threaded app say bash for
few heavy used calls in libc say read/select systemcall stub. If this user
wants to keep recording at discreet intervals.  i.e record for 5 minutes,
stop for 5 minutes, record again for 5 minutes, ....  Can you list how you
would go about inode based probe insertion / probe deletions?

> 
> >  Just to clarify, I am not looking at probing per task
> > but probing per process. So the pid field in uprobe refers to the
> > tgid. 
> 
> Urgh,.. I really oppose the whole pid-centric thing, if that means
> process wide and not per task its even worse.
> 

Since breakpoints are shared across the tasks of the same process, we cant do
per-task based tracing. We can only do a per process tracing and filter
per-task which if the request is for per-task tracing and thats what I
think you were alluding to in the filter in one of your mails. I am okay with
filtering per-task within a given process.

--
Thanks and Regards
Srikar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/