Hi Hans, (I'm copying perf-discuss, since I think this discussion will probably be of general interest, and the wider forum can probably provide you with feedback about expected use cases).
Hans Rosenfeld wrote: > Hi, > > I would like to lift the major limitation of the IBS provider, its > inability to support enabling multiple probes with different sampling > periods. It can currently only be enabled system-wide, and it only > supports one sample period for each the fetch and the exec probes. > > I thought about how to change that, but the only useful way seems to be > extending the provider to allow thread- or process-specific enablements > of the probes, in addition to the possibility of system-wide sampling. > (Just ignoring the sampling period for new probe activations would be > another, very simple-minded approach. I don't know whether this would > actually be useful.) > > These thread- or process-specific probes would be enabled and disabled > with the context switch to or from user mode. This would probably > require some quite intrusive changes to the context switch mechanism, > which would probably trigger a lot of people who would surely be very > skeptical about that. > > Since I currently do not know enough about the DTrace provider API and > the context switch code to just implement that, I got some time to > request some input on that issue. It is quite possible that this > approach completely misses the point of what people actually want to do > with the IBS provider, and if thats the case I would like to know before > I start any coding :) > On the face of it, I wonder how different this problem is from the one faced by the cyclic subsystem. It implements an arbitrary resolution interval timer facility, currently backed by the APIC timer (on x86). The same sort of problem arises when you want to use one APIC timer to implement multiple cyclics (where each cyclic will result in the execution (firing) of a handler at some time interval). It uses a heap for this, where the top of heap represents the next scheduled firing...so when a given cyclic fires, the APIC timer is programmed (in one shot mode) to fire when the next one is due. usr/src/uts/common/os/cyclic.c has some of the best documented code in the kernel, you might be interested in taking a look... Thanks, -Eric _______________________________________________ perf-discuss mailing list [email protected]
