Messages in this thread | | | Date | Mon, 23 Aug 2004 09:27:35 -0700 | From | wli@holomorp ... | Subject | Re: 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/
| |