Re: 2.6.8.1-mm3

[wli@holomorphy.com]

On Fri, 20 Aug 2004 13:02:48 -0700, William Lee Irwin III said:
William> I suppose another way to answer the question of what's
William> going on is to fiddle with ia64's implementation of
William> profile_pc(). I suspect something like this may reveal the
William> offending codepaths.

On Mon, Aug 23, 2004 at 02:02:42AM -0700, David Mosberger wrote:
> You do realize that q-syscollect [1] can do this better for you
> without touching the kernel at all?
> [1] http://www.hpl.hp.com/research/linux/q-tools/

Never heard of it. Unfortunately, the issue I run into far more
frequently than tools not existing is users being unwilling or unable
to use them. In fact, it's even a relatively large hassle to get users
to boot with /proc/profile enabled regardless of its simplicity. For an
issue this common I would prefer that the most basic tools available
(i.e. the very few that are near-universal, e.g. readprofile(1) etc.)
report callers to spinlock contention by default.

That said, should other concerns override mine, and the decision is to
report the precise program counter for /proc/profile at all times for
all architectures, that decision would eliminate profile_pc() in favor
of instruction_pointer(), further consolidating /proc/profile code.


-- wli