Stephane Eranian wrote:
Stephen,
On Fri, Sep 15, 2006 at 02:38:34PM -0400, Stephen Ziemba wrote:
Stephane,
Are you saying the removal of kapi support is temporary or possibly permanent?
I meant it is temporary. I think there is a need. We just need to demonstrate
that certain measurements cannot be done differently without incurring
a huge penalty.
At this point, I think it is more important to get perfmon without kapi
accepted into mainline than delay the whole thing because people do not
understand why kapi could be useful.
I understand prioritization of the work in the perfmon support. Certainly get
the user-space support so that people can use the the performance hardware on
user applications in first.
During that meantime, we need to build a stronger case, and your tool may be
helpful in that. I would encourage you to describe it on lkml and here.
We could also use this time window to refine kapi and make sure we find
and understand all the usage restrictions it has.
>
You stated you have pulled kapi support until a vey strong case can be made for
it. I assume you are saying you are removing perfmon_kapi.c and the associated
code from future perfmon kernel patches. The tool I am currently developing
utilizes the kapi interface and was hoping for clarification on the future
support of kapi. I use neither overflow nor timer based samples and instead
sample on specific kernel events. All monitoring is done within the kernel for
the kernel. The only time any of this information is exported to user is for
debugging or further analysis. It seems without kapi any tool designed to have
the kernel monitor specific aspects of itself will have increased overhead.
Stephen Ziemba
Electrical and Computer Engineering
Purdue University
[EMAIL PROTECTED]
At the very least there needs to be a mechanism to read the values of the
performance monitoring hardware registers in kernel-space. Certainly people have
used get_cycles() to see how long certain things take to do within the kernel.
Having access to the performance monitoring counters would allow better testing
of some hypothesis, e.g. were there fewer or more cache misses with this
approach versus another approach. It isn't practical to do the read of the
performance counter in user-space. Too bad that the performance hardware
designers for most processors took short cuts, so that a simple direct reading
of the perfmon hardware data counters won't work.
-Will
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
