This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Multiple kprobes at an address redux (take3)


Hi -


On Tue, Apr 12, 2005 at 09:29:34PM +0530, Suparna Bhattacharya wrote:
> [...]
> > Can you conceive of a way of (a) leaving the kprobes low-level code
> > and its existing clients unchanged, and (b) allowing a higher layer to
> > support colocated probes, and (c) allowing a higher layer to enjoy
> > concurrent probe execution?
> 
> Improving kprobes scalability would be an enhancement belonging in the
> lower layer of course, but that is really independent of the multi-probe
> feature. You just want the ability to process kprobe hits on different
> processors concurrently.

Yes.  But if kprobes starts allowing that, then this triggers your
argument about how current kprobes users would have to change their
code (like adding mutexes).  If such an interface change is tolerable,
then they will likely also accept colocated probes, especially if they
are implemented as efficiently as Ananth's last version does.


> [...]
> OK, so you really are thinking of independent systemtap sessions, not
> co-existence with other unrelated kprobe users.

Does one really have to separate the cases?  Maybe one administrator
wishes to run some hand-written kprobes, while another wants to run
some packaged systemtap trace script.  The two efforts should not
block each other unless absolutely necessary.

> As I mentioned above if the basic kprobes concurrency issue is
> solved that should address your primary concern, right ?

Maybe.

> (Was something like a per-probe reader-writer lock that you were
> thinking of, or am I misinterpreting ?)

I did not imagine per-probe locks within kprobes.  Rather, I imagined
the least restrictive locks possible that are necessary within kprobes
to protect its internal lookup tables and state.  A read/write version
of the big kprobes_lock might be sufficient to allow concurrency
during probe handler execution, assuming that holding a read lock is
sufficient for these.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]