The hwpmc(4) log contains virtual addresses of sampled instructions.
pmcstat(8) aggregates these into per-function counts when generating
gmon.out files for input to gprof(1). If you want an instruction
level listing instead, please use the pmcannotate(8) tool.
At this time you cannot selectively profile portions of the code.
Profiling is done either on a per-process basis, or for the whole
system, depending on the 'mode' of the allocated PMC.
Fine-grained control of PMCs would require (a) that hwpmc(4) grow an
in-kernel API and (b) that this API be used by an in-kernel module
such as dtrace(4).
> 2.When I use the tool, What kinds of inaccuracy should I expect?
The "precision" associated with sampling is dependent on that provided
by the processor. Some hardware events are inherently imprecise,
i.e., the PMC interrupt is taken within a few instructions of the one
that caused the counter overflow. In some processors, some events are
precise when configured on certain counters but are imprecise
otherwise. The manufacturer's documentation usually lists which are
which.
In counting mode, the RDPMC instruction used to read counters also has
a small window of imprecision. See documentation for more details.
> 3.Even I did some research on PEBS, if I want to added to current PMC tool,
> I have to somethings to do,such as configuring the DS buffer in the kernel,
> the DS buffer overflow ISR handling,configuring the pmc register,etc. I find
> it a lot of work to do. But from your expert point of view, how much work do
> you think?
It is a lot of work to do. :)
Note that with PEBS the processor saves its entire register state at
the time of the PMC interrupt to a memory buffer. Even if hwpmc(4)
were augmented to capture this information, we do not have userland
tools that can work with information at that level of granularity.
Further, IIRC, PEBS mode does not walk call chains, so callchain
capture still needs to be done explicitly by hwpmc(4).
HTH,
Koshy