Hi James, I've done some further experimentation and I think I'm going to keep a minimum overflow rate but have it at 5000. The reason for this is that it gets fairly easy to drive a system off the rails by setting values much lower when measuring kernel cycles. I use cycles as that's obviously the fastest incrementing of all events. At rates not far under 5000 we get wedged up in interrupt code; servicing regular interrupts and piling in and out of overflow handler code. Without this limit it's just too easy for some well meaning but keyboard challenged user to put the lights out.
As you state in your original example though, we could employ a significantly lower overflow value for userland code and we can even work with values in single digits. However, it goes without saying that with overflow values this low the forward progress of an application tends to zero. If someone wants to do this then that's fine and they can tune the minimum overflow rate down manually. If, when people start using the provider, I get feedback that this approach needs modifying then I'll happily revisit but I'll implement it as I stated here for the first pass. Jon. > On Jul 14, 2008, at 3:42 AM, Jon Haslam wrote: > > >> Tracing Fans, >> >> I know it's been a long time in coming but the CPU Performance >> Counter (CPC) provider is almost here! The code is currently in >> for review and a proposed architecture document is attached here >> for review. >> > > Very cool :-). > >> 4. Limiting Overflow Rate >> >> So as to not saturate the system with overflow interrupts, a default >> minimum >> of 10000 is imposed on the value that can be specified for the 'count' >> part of the probename (refer to section 'B1 - Probe Format'). This >> can be >> reduced explicitly by altering the 'dcpc_min_overflow' kernel >> variable with >> mdb(1) or by modifying the dcpc.conf driver configuration file and >> unloading >> and reloading the dcpc driver module. >> >> > > You may need a "per type" of overflow limit. A 3 - 4GHz cpu will > generate > 300k - 400k events per second when tracking cycles. > > Some of the more exotic cache behavior counters might fire only 1-2k > events > per second, though. When you combine that with the need for the > counter to fire while > inside the application you are interested in, a 10k event minimum > seems too small. > > Does a minimum limit actually buy much here? > > Consider the case of: > > cpc:::FR_retired_x86_instr_w_excp_intr-user-10000 > > vs > > pid123::: > > In this case, the cpc probe is actually less capable! If the pid > provider can generate one event per instruction, without a safety > limit/check, > does the CPC provider really need a safety limit? > > James M > > _______________________________________________ > dtrace-discuss mailing list > [email protected] > _______________________________________________ dtrace-discuss mailing list [email protected]
