Re: [perfmon2] [PATCH] 1/1 - add kernel support for POWER4 and POWER6 to perfmon2
Status: Beta
Brought to you by:
seranian
From: Corey A. <cja...@us...> - 2007-11-29 21:35:26
|
Sonny Rao wrote: > On Thu, Nov 29, 2007 at 01:28:57AM -0800, Corey Ashford wrote: > <snip> >> > >> > What you are missing at this point is interrupt-capability for >> > this virtualized counter. I believe this can be emulated on top >> > of what you have, and here is how this could be done: >> > >> > - make virtual counter 5 & 6 writeable >> >> They already are writeable in the current implementation. >> >> > >> > - keep your timer-based sampling and accumulation scheme >> > >> > - when you accumulate, check that the new value is greater than >> > the previous value, if not then: >> > - set bit 5 or 6 in set->povfl_pmds, set->npend_ovfls++ >> > - post the PMU interrupt >> >> That could be done, but the timing of the "interrupt" will be anywhere >> from 0 to 250ms late since we are sampling the counters at about 4Hz. >> That's pretty far off. >> >> > >> > That should work. The corner case, of course, is what happens if you also have >> > simultaneous interrupts from other counters at the same time? For that, I think >> > you'd have to craft the get_ovfl_pmds() routine to take this into account. >> > >> > >> >> Right, that will take some thinking. > > Corey, the right thing to do here might be to simply use one of the > groups that had cycles or instructions on pmc1-4 if the user wants > overflow notification... I'm not sure if the interface in libpfm lends > itself to that however. If it doesn't, can we simply say we don't > support overflow notification for PMC[56] on POWER6 (less than 64bit) > ? Phil Mucci and Stephane are looking into changing the interface so that the caller can discover that a particular counter does not support interrupt on overflow. I think libpfm can be made smart enough to choose a group that meets the desired constraints of events, privilege level, and interrupt capability. It already handles the first two. > I think most users will just want 64bit virtualization of those > counters anyway and aren't concerned about intermediate overflows. > > Sonny Well, some are going to want to use 64-bit overflow for sampling, and I think we need some way of telling them that a particular counter won't provide an accurate notification of overflow (or possibly any notification at all). Consider the case where a processor has a 64-bit counter that doesn't require polling for intermediate overflows, but doesn't generate an interrupt on 64-bit overflow. There wouldn't be much motivation to add code to the kernel that polls for overflow because it would be wasteful and pretty limited in accuracy. Another thought would be to sample these 32-bit counters on every system tick (same as jiffy?). That would add some overhead, but would give the user an interrupt within a jiffy of overflow. I don't know how accurate the notification needs to be. How accurate is accurate enough? How much slop is simply unacceptable? I'd guess the answer really depends on the application and the goals of the sampling. - Corey -- Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 cja...@us... |