* David Miller <davem@xxxxxxxxxxxxx> wrote: > > > Isn't it two separate read() calls to read the two counters? If > > > so, the only way the two values are actually going to correspond to > > > the same point in time is if the task being monitored is stopped. > > > In which case the monitoring task needs to use ptrace or something > > > similar in order to make sure that the monitored task is actually > > > stopped. > > > > It doesnt matter in practice. > > Yes it DOES! > > If I want to know if a code block triggers event X or Y, and your read > call triggers one of those events, I can't figure out the answer to my > profiling problem. ( this misunderstanding of yours has been cleared up in a later mail: reading a counter causes events in the monitoring context, not in the monitored context. ) > That is completely fundamental to all of this. And this is why this > proposal is a non-workable solution. > > > > Also, look at our code: we buffer notification events and do not have > > to stop the thread for recording the context information. > > But that's what monitoring libraries want, they want to stop the task > and inspect it. > > Look at the PAPI library. If you can't implement what that thing > provides, all the real users of profiling information can't use this > stuff. We have looked, and the PAPI library can be implemented on top of our system call as well - just like it was implemented on top of the perfctr driver and like it was implemented ontop of "perfmon-full". PAPI is a relatively simple wrapper around OS level performance counter facilities. Both the high level counter abstraction (PAPI_start_counters() & friends) and the low level PAPI abstraction (PAPI event sets, PAPI_attach/detach) can be readily implemented via the use of our performance counter subsystem facilities. (In addition to all the facilities around PAPI event enumeration.) PAPI has about 100 functions - if you think our design does not fit it for some fundamental reason then please point out exactly which functionality (which PAPI function call) cannot be done. Perfmon needlessly complicated their design by exposing user-space to a 'performance counter context' and other lowlevel details that should not and must not be handled at the ABI level. The PAPI interfaces do not force that design choice in any way. It's a plain unnecessary complication that permeates the whole perfmon code. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
