Hi Hans, Firstly, I think that I'd like to see the IBS provider putback into Solaris so that people can gain real world exposure to it. I understand that, on the surface of it, having just a single probe to play with may seem restrictive but it would be good to see what people can turn up with it in its current form and then expand it after that. I have implemented the CPC provider and it faces the same problem; we have finite hardware so how can we share that around. My first implementation which I aim to putback soon (currently under review) takes exactly the same approach that the IBS provider does in that I don't do any fancy multiplexing of events or virtualisation of counters. Once we've gained some real life use out in the field I think we'll know whether or not this is good enough or if we need to do more.
As a side note I spoke to Eric about the possibility of integrating the IBS provider quite some time ago but that's fallen down the queue (for me at least). Someone needs to pick it up and integrate it some time... With regard to virtualising the sampling hardware on a per thread/process basis; I think we need to be careful here as there are several sampling technologies that need to be accommodated. A while ago Russ Blaine kicked off some investigations to look at requirements for a generic sampling framework but I'm not sure what the outcome of that was. Maybe Russ can shed more light on this if he's tuning in here? I think that's quite a piece of work though. Jon. >> 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 > perf-discuss@opensolaris.org > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
