[perfmon] Re: perfmon2 TODO list (4/4)
Frank Ch. Eigler
fche@redhat.com
Thu Apr 13 23:05:00 GMT 2006
Hi -
Josh wrote:
> I would hate to require SystemTap to know all of the possible
> variations that should be included in the fat binary - that is the
> point of having libpfm in the first place.
We would still use libpfm itself, but instead of asking it to generate
PMC data for one particular CPU only, we would ask it to generate
several candidates.
> A statement like "all within an architecture" is still painful when
> dealing with the P4.
How painful do you mean? A few dozen variants would still take only a
couple of hundred bytes of "fat" PMC data.
> In a "delayed-resolution" model, SystemTap can remain ignorant of
> architectural differences.
Downsides of having stpd resolve this stuff include the loss of
proximity to script code for purposes such as error localization,
advice heuristics; reliance on a smarter stpd precludes operation
without it (such as in the boot-time probing scenario of bug #2035);
it could preclude representation of CPU flavours to tapsets for
purposes of event name abstraction.
- FChE
More information about the Systemtap
mailing list