I think I'm still struggling with semantics of these two and why they need to be separate. That along with the limitation that you can do certain things before and after loading the context, all seem rather unnecessarily limiting to me.
To clarify a little, the first change, like being able to declare a sample buffer at any point (as well as multiplexing set etc...) upon create_context time, means that contexts cannot be created until one knows exactly what one is going to do with the PMU. This is not the case, often a library wants to create a context for itself or another process, attach that process, and anything may be done to it, adding sets, sampling, etc. The current model requires that all such changes follow a unload/context/close/create/context/load/context cycle in virtually all paths resulting in changing the usage model of the counters. Consider the user, using a performance tool with an interactive interface to the counters...you don't know that the user is finished 'setting up' things until he or she calls start. That means either you defer creation and loading until start or you go through unloading and closing. On my second point, I really see no circumstances where create runs and load doesn't. These two are always used together...currently it seems that this only provides some sort of external gate to still be allowed to change less things once loaded. (You can really only read and write PMD/PMC's after this). Looking through all of pfmon, libpfm and PAPI, seems to indicate that if load_context were implicit in create_context, the code would be simpler and smaller...if you need to declare PMU resources, at create time would be just as useful and require one less API call and one less kernel entry point. I know you have explained the rationale of these to me numerous times, but I still see the same code snippets all through the libraries...create/write/write/load...and I can't help but wonder if that can be reduced to one simple kernel call. The fact that I do this sequence means that if the user changes how he or she uses the counters, I have to do 6 system calls to reuse the counters...unload/close/create/write/write/load. But this is as much as I want to say...really, if they accept Perfmon2, no one will be happier than me. (ok you maybe ;-) On Thu, 2006-11-02 at 03:21 -0800, Stephane Eranian wrote: > > > > Why don't they make useful suggestions, like being able to declare > the > > sample buffer outside of the create/load context call or removing > the > > load/create pair altogether. These changes maybe LKML friendly, but > they > > do not make programming the API any more flexible or robust. > > Could you develop a bit more on those two points? What would it buy > you? > I am not sure I understand 'remove create/load'. How would you declare > you need the PMU resource? > _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
