Phil, On Tue, Nov 07, 2006 at 02:25:45PM +0100, Philip J. Mucci wrote: > Hi Stefane, > > Thanks for the explanations....while I understand that the load/create > split is supposed to make things more efficient, my answer is that it > does not in practice, due to the way the counters are used. You could > say that this is a by-product of PAPI design (or the libpfm test suite), > but it just is the way it is. > > As for sampling buffer, I don't agree that the tools knows whether > and/or how much it is going to sample when the context is created. Any > more than a debugger knows what your going to do when you ptrace_attach. > Same goes for multiplexing. The flexibility present in multiplexing can > be narrowed...sublists for example...and next set notification. My > feeling is that this will never be used and both introduce complexity > and restrictions into the underlying code. This is one of the *very few* > cases where I agree with criticism about too much > flexibility/configurability of perfmon. Just because something is > possible (and because we can think up a way to use it), doesn't mean > that the support should be there. Sublists and next-event-set type > semantics could be emulated in user land if someone really wanted > it...furthermore, it's unclear that any real or imagined performance > tools out there will use it. (IMHO) To this end, I would definitely not > support adding a function call, but rather: > > deleting sample buffer args to context create > removing event_set entry points > replace all of the above with perfmon_ioctl() for such things. > Keep in mind that the top maintainer do not like ioclt() style of system calls. That is what we had initially.
I am not willing to add any new system calls at this point. So I think we'll get the creat/smpl buffer allocate together. You are right that at this point the explicit next-set is not used in any tools. As such, one could consider this experimental. The amount of code involved is fairly minimal. I am willing to remove this for now. I do think we could relax the constraints on set creation and possibly deletion when the context is loaded. I think it is pretty easy to accept creation of next contexts. Keep in mind, that pfm_create_evtsets, is used to create a brand new set but also to modify an existing set. The latter being more difficult to support when the context is attached (because you may be modifying the current active set). I need to take a look at this. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
