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]

kprobes layer improvements


Hi -


To recap, there are three known plans to improve the kprobes layer:

- support for multiple probes at the same address
- concurrency across SMPs
- return probes

Only the last one technically requires new API: the first two can be
implemented behind the ordinary existing "register_kprobes" APIs.
(One of Ananth's prototypes did just this, and efficiently, for #1).


It seems to me that people are overly concerned about the multi-probes
issue, when that is a small potato.  Yes, programs that might have
previously failed to initialize (due to an error signal from multiple
kprobe registrations) may now succeed, and run unaware of each other.
This is little more than a functional enhancement, like allowing more
than one process to create timer callbacks for the same moment.

Note that the overall effect of implementing this support as a new
layered API is small, as long as the implementation is in the kernel
and not in the per-session runtime state.

If the user population needed to be polled about this function, the
question should be phrased something like ... "Dear kprobes user.  Do
you intend to write now, or have you at any time written in the past,
a kprobes application that would break if another application happened
to run an independent, invisible-to-you kprobe at the same locations?"
If the answer is universally "no", then inventing a new API just for
the multiple case almost certainly unnecessary.


The second extension should be much more controversial.  In order to
avoid obscuring SMP phenomena, and for better performance, we believe
it is necessary to be able to run probes concurrently across multiple
processors with a minimum of mutual exclusion.

This could mean that an existing kprobes user might encounter
unexpected reentrancy into her code.  Since this sounds like a
reasonable concern, the API should allow an application to request
kprobes to maintain its previous non-reentrancy non-concurrency
properties with respect to those probes.  Maybe this should even be
the default.  Of course, systemtap would use the "bring it on!"
setting.

Note that this cannot be practically implemented as a layered API
(using an unchanged kprobes layer), because of the current use of
kprobes_lock.  Note also that concurrency & multiplicity may compose
in an interesting though not troublesome way.


I am not familiar enough with the function-return probes to know to
what extent the presence or absence of features #1/#2 above would
affect the possibility of a layered implementation.  It seems unlikely
to be a compatibility-breaking controversy amongst kprobes-classic
users, and thus doesn't seem to justify an user-base poll.


- 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]