Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

[Stephane Eranian]

Hi,

On Fri, Jun 16, 2006 at 02:50:14PM +0100, Christoph Hellwig wrote:
> On Thu, Jun 15, 2006 at 02:07:38AM -0700, Stephane Eranian wrote:
> > This patch contains the kernel-level API support.
> 
> NACK.  No one should call this from kernel space.
> 

Well, that's what I initially thought too but there is a need from the SystemTap
people and given the way they set things up, it is hard to do it from user level.

> and apparently noting in your patchkit does either, so this is just dead code.

I have not immediate need my self, but I have received several requests for
this, systemtap being one of them.

-- 
-Stephane

Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

[Christoph Hellwig]

On Fri, Jun 16, 2006 at 07:02:34AM -0700, Stephane Eranian wrote:
> Well, that's what I initially thought too but there is a need from the SystemTap
> people and given the way they set things up, it is hard to do it from user level.

Systemtap doesn' matter.  Please don't put in useless stuff for their
broken requirements - they're all clueless idiots.

Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

[Alan Cox]

Ar Gwe, 2006-06-16 am 15:56 +0100, ysgrifennodd Christoph Hellwig:
> On Fri, Jun 16, 2006 at 07:02:34AM -0700, Stephane Eranian wrote:
> > Well, that's what I initially thought too but there is a need from the SystemTap
> > people and given the way they set things up, it is hard to do it from user level.
> 
> Systemtap doesn' matter.  Please don't put in useless stuff for their
> broken requirements - they're all clueless idiots.

Christoph, thank you for your detailed analytical analysis. The kernel
list would not be the same without your detailed, well explanation and
reasoned rational analyses

Alan

Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

[Frank Ch. Eigler]

Stephane Eranian <eranian@hpl.hp.com> writes:

> > > This patch contains the kernel-level API support.
> > NACK.  No one should call this from kernel space.
>
> Well, that's what I initially thought too but there is a need from
> the SystemTap people and given the way they set things up, it is
> hard to do it from user level. [...]

Whether one uses systemtap, raw kprobes, or some specialized
tracing/stats-collecting patch surely forthcoming, kernel-level APIs
would be needed to perform fine-grained kernel-scope measurements
using these counters.

- FChE

Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

[Christoph Hellwig]

On Fri, Jun 16, 2006 at 11:41:32AM -0400, Frank Ch. Eigler wrote:
> Whether one uses systemtap, raw kprobes, or some specialized
> tracing/stats-collecting patch surely forthcoming, kernel-level APIs
> would be needed to perform fine-grained kernel-scope measurements
> using these counters.

No, there's not need to add kernel bloat for performance monitoring.
This kind of stuff shoul dabsolutely be done from userspace.

Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

[Frank Ch. Eigler]

Hi -

> > Whether one uses systemtap, raw kprobes, or some specialized
> > tracing/stats-collecting patch surely forthcoming, kernel-level APIs
> > would be needed to perform fine-grained kernel-scope measurements
> > using these counters.
> 
> No, there's not need to add kernel bloat for performance monitoring.
> This kind of stuff shoul dabsolutely be done from userspace.

Userspace measurements provide only large-grained quantities.  Can you
argue convincingly that there is never a need to measure focused
quantities such as cache behaviors of individual subsystems, branch
prediction statistics of a new algorithm?  That running system-level
benchmarks is the most efficient way for developers to assess their
changes?  That the scheduler would not benefit from access to HT
resource utilization statistics?  All these sorts of efforts seem
to require a kernel-side perfmon API.

- FChE

Re: [perfmon] Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)

[William Cohen]

Stephane Eranian wrote:
> Christoph,
> 
> On Fri, Jun 16, 2006 at 04:45:19PM +0100, Christoph Hellwig wrote:
> 
>>On Fri, Jun 16, 2006 at 11:41:32AM -0400, Frank Ch. Eigler wrote:
>>
>>>Whether one uses systemtap, raw kprobes, or some specialized
>>>tracing/stats-collecting patch surely forthcoming, kernel-level APIs
>>>would be needed to perform fine-grained kernel-scope measurements
>>>using these counters.
>>
> You do not need to be in the kernel to measure kernel level
> execution. Monitoring is statistical by nature, this is not about capturing
> execution traces. All PMU models have the capability to filter on privilege
> levels so you can distinguish user from kernel.
> 
> To measure certain functions of the kernel, some PMU models provide a
> way to restrict monitoring to a range of contiguous code addresses, e.g.
> Itanium 2. 

The filtering on privilege level is too coarse. For example want to 
start event counting on entry into a kernel function and stop when 
exiting the function. The itanium hw is not ideal for this application. 
The children functions may not be contiguous with the starting function. 
  Other kinds of predication based on state information, e.g. particular 
process or thread could be very useful.

> The case of systemtap is different. I think they would like to start/stop
> monitoring on certain systemtap events, e.g., a function is called, a
> threshold is met. Start and stop would be triggered from a systemtap
> callback which is implemented by a kernel module, if I understand
> the architecture. In the scenario, the monitoring session would have
> to be created and controlled from the kernel. One could envision an
> architecture, where monitoring would be controlled from user level 
> with systemtap making upcalls  but I do not think this is possible given
> that the instrumentation points can be very low level.
> 
> Another usage for a kernel-level monitoring API that I know about is 
> people who want to explore how to use the performance monitoring
> (and profiles) to guide the scheduler. A thread profile can tell the cache
> hit rates, stalls, bus bandwidth utilization, whether it uses flops and so on.
> This could be useful to to find the best placement for threads and avoid co-scheduling
> threads that trash each other's micro-architectural state or saturate the memory bus.
> In this scenario, one could envision a kernel thread controlling monitoring
> and processing profiles for the scheduler. But, to concur with you Christoph,
> I think this could be achieved from user level and the valuable information
> may be passed to the scheduler via a specific system call for instance.

One probably could configure the performance monitoring hardware from 
userspace. However, for micro-measurement in the kernel it seems like 
the pmu reads in kernel space would still be required.

-Will