lkml.org 
[lkml]   [2004]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.8.1-mm3
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.181 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site