Phil,
Now that we've larified the first half of your message, let me comment on the rest. On Mon, Aug 28, 2006 at 10:07:11PM +0000, Philip Mucci wrote: > Consider one or more of the following: > > A) Removing create/destroy/getinfo eventsets entirely and make them > implicit in the read/write pmcs/pmds call. I don't entirely grok why > they are separate anyways, since you can't really reuse eventsets for a > new set of PMCS that are being multiplexed...surely there are different > number of sets and the mapping is different. I thought about doing the create set on first reference via pfm_write_pmds or pfm_write_pmcs but then I decided not too because I don't thin it is that clean. It is better if you have to explicitely create set. You would need a set related call anyway to extract some set-specific information such as the actual number of activations of a set (which is used in the scaling computation). As for reuse, sure you can. The pfm_create_evtsets is there for creation AND modification. This is how for instance you can set the switch timeout for set0 which is there by default. You can use this call on an existing set to adjust the timeout for instance or change the set from timeout to overflow based switching. But there is another advanced feature of event sets which requires that the list of sets be fully defined before you attach. By default the set identification determines the switch order. Sets are switch to in increasing number of their identification,e.g., 0->2->5. You can have holes of course. But a user may choose to force a different switch order by specifying the next set. So you can effectively creates sublists. You switch from one list to another by stopping and then restarting (with pfm_start) by passing the identification of the new set to start from. This all mechanism is useful because it lets you prepare a bunch of distinct event lists at once, and then you can alternate between lists. But you need to validate that all sets have a valid switch_to destination and that can be done at load time once if you disallow creating/deleting while attached. > > B) Relaxing the restriction of load_context. This would at least allow > one to gracefully do lots of things with different counters without > unloading and loading a context everytime you had a different number of > eventsets. > See my response on your first part. > C) Adding a call (or a flag to a call) that writes the PMCS, zeros all > the values of the corresponding PMDS and starts the counters rolling. > Seems like every example in libpfm does the same sequence of > write/write/start... > The kernel does not know the relationship between PMCS and PMDS and should not know otherwise it create real headaches and complexity as for many PMU models, it is just a one to one mapping (1 PMC controls 1 PMD). There is another detail that works again doing this. Perfmon does not let you read a PMD which you have not requested via pfm_write_pmds or by specifying it as part of reg_smpl_pmds or reg_reset_pmds. The motivation for this as to do with security and performance. This restrictions allows us to speed up context switching by not having to restore all PMDS but just the ones you effectively use without compromising security. Of course, when you request direct access at user level via rdpmc, we do have to clear all PMDs. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
