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