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