This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Christoph Hellwig <hch at infradead dot org>, eranian at hpl dot hp dot com, linux-kernel at vger dot kernel dot org, systemtap at sources dot redhat dot com, wcohen at redhat dot com, perfmon at napali dot hpl dot hp dot com
- Date: Fri, 16 Jun 2006 12:18:06 -0400
- Subject: Re: [PATCH 9/16] 2.6.17-rc6 perfmon2 patch for review: kernel-level API support (kapi)
- References: <200606150907.k5F97coF008178@frankl.hpl.hp.com> <20060616135014.GB12657@infradead.org> <20060616140234.GI10034@frankl.hpl.hp.com> <y0mhd2lumz7.fsf@ton.toronto.redhat.com> <20060616154519.GA28931@infradead.org>
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