[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4E78D2A2.6010106@linux.intel.com>
Date: Tue, 20 Sep 2011 10:51:30 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC: Andi Kleen <andi@...stfloor.org>, acme@...stprotocols.net,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] perf_events: Support a lock_parent event flag
> This all just sucks horridly. So this name tells us we need inherited
> counters so that whenever we encounter a lock it will be accounted in
> the parent process, or whatever -- which doesn't make any sense.
Thanks for the kind words. So what name do you suggest?
account_in_caller_of_lock ?
i_write_a_novel_in_every_variable_name?
> Furthermore, the sole reason you want this is because you don't want
> callchains, supposedly because they're too expensive, but then you don't
> say that.
perf top doesn't support callchains. And yes it's a lot cheaper too, but
that wasn't
the main motivation. perf top is just useless to diagnose any lock problems
currently.
I say that in the changelog for the user space.
> How about you provide means of limiting the callchain depth, and then
> frob the in_lock_function() and unwind 1 crap in userspace?
Is that equivalent? The normal call chains don't work without frame
pointers.
profile_pc does.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists