On 9/23/14, 12:00 PM, Namhyung Kim wrote:
> + unw_set_caching_policy(addr_space, UNW_CACHE_GLOBAL);
The result is a bit surprising for me. In micro benchmarking (eg:
Lperf-simple), the per-thread policy is generally faster because it
doesn't involve locking.
libunwind/tests/Lperf-simple
unw_
On 4/1/14, 12:58 PM, Namhyung Kim wrote:
gdb attributes 0x10370 to a different/known symbol.
(gdb) x /i 0x10370
0x10370 : cmp$0x4c,%dl
Is this known? Could this possibly be caused by stale histogram entries from
unmapped/remapped shared libs?
Possibly.
Anyway the addr which pe
On 3/20/14, 11:06 AM, Namhyung Kim wrote:
Hello,
This is a new attempt to implement cumulative hist period report.
This work begins from Arun's SORT_INCLUSIVE patch [1] but I completely
rewrote it from scratch.
While testing this patch series, we found error messages which look like
this:
O
On Mon, Feb 3, 2014 at 7:28 AM, Jean Pihet wrote:
>> Something like ./configure --target=arm on aarch64.
>
> Thanks for the link and info.
>
> Is there a concrete example of cross-unwinding with multiple targets,
> for example on x86_64 using native and x86_32 libunwind libraries
> simultaneously
I promise ;-)
We've been testing v5 of this patch series and haven't found any major
problems on our end.
Tested-By: Arun Sharma
-Arun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
On 12/18/13 8:09 PM, Namhyung Kim wrote:
Hi Arun,
2013-12-18 (수), 16:08 +0530, Arun Sharma:
On 12/18/13 3:16 PM, Ingo Molnar wrote:
My main complaint that any variation of 'cumulative' or 'cumulate' is
a tongue-twister to users. I certainly won't be able to remember
On 12/18/13 3:16 PM, Ingo Molnar wrote:
My main complaint that any variation of 'cumulative' or 'cumulate' is
a tongue-twister to users. I certainly won't be able to remember it
and will have to call up the manpage every time I use it - which will
be very annoying. I'd probably not use the featu
On 10/28/13 8:11 PM, Namhyung Kim wrote:
Hey Namhyung:
Also, what's the reasoning for --cumulate not being an option under
perf record -g ..,?
Sorry, I cannot understand you. The 'perf record' just saves sample
data (and callchains) from the ring-buffer. All the processing happens
in 'perf
On 10/28/13 2:29 AM, Rodrigo Campos wrote:
On Mon, Oct 28, 2013 at 06:09:30PM +0900, Namhyung Kim wrote:
On Mon, 28 Oct 2013 08:42:44 +, Rodrigo Campos wrote:
On Mon, Oct 28, 2013 at 02:09:49PM +0900, Namhyung Kim wrote:
Anyway, You can find the series and discussion on the link below:
On 9/5/13 12:47 AM, John Stultz wrote:
If we're going to add a new interface that uses something other then a
timespec, we likely need to put some serious thought into that new
type, and see how it could be used across a number of syscalls. Some
of the discussion around dealing with the 2038 issu
A couple of years ago Andy posted this patch series:
http://thread.gmane.org/gmane.linux.kernel/1233209/
These patches have been in use at facebook for a couple of years and
along with a vDSO implementation of thread_cpu_time(), they have proven
useful for our profilers.
I didn't see any arg
On 12/17/12 10:47 PM, Minchan Kim wrote:
I hope more inputs from user-space allocator people and test patch
with their allocator because it might need design change of arena
management for getting real vaule.
jemalloc knows how to handle MADV_FREE on platforms that support it.
This looks simi
On 11/5/12 5:49 PM, Minchan Kim wrote:
Also, memory allocators have a second motivation in using madvise: to
create virtually contiguous regions of memory from a fragmented address
space, without increasing the RSS.
I don't get it. How do we create contiguos region by madvise?
Just out of curi
On Wed, Oct 31, 2012 at 06:56:05PM -0400, KOSAKI Motohiro wrote:
> glibc malloc discard freed memory by using MADV_DONTNEED
> as tcmalloc. and it is often a source of large performance decrease.
> because of MADV_DONTNEED discard memory immediately and
> right after malloc() call fall into page fau
On 10/29/12 12:08 PM, Peter Zijlstra wrote:
Right, so I tried this and I would expect the callchains to be inverted
too, so that when I expand say 'c' I would see that 'c' calls 'b' for
100% which calls 'a' for 100%.
Instead I get the regular callchains, expanding 'c' gives me main calls
it for
On 10/15/12 8:55 AM, Robert Richter wrote:
[..]
Perf tool works then out-of-the-box with:
$ perf record -e cpu/stalled-cycles-fixed-point/ ...
The event string can easily be reused by other architectures as a
quasi standard.
I like Robert's proposal better. It's hard to model all the stall
On 9/13/12 12:19 AM, Namhyung Kim wrote:
Hi,
This is my first attempt to implement cumulative hist period report.
This work begins from Arun's SORT_INCLUSIVE patch [1] but I completely
rewrote it from scratch.
Tested-by: Arun Sharma
Our typical use case:
perf record -g fp ./foo
perf r
On 8/28/12 9:34 AM, Peter Zijlstra wrote:
It used to look like this:
http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=commitdiff;h=92cc7fd78a5a79c4bb5f85bfb7d7fb025df9cd5a
Hmm, that's not too bad, but a long stretch from pretty ;-)
How would you 'encode' this in the perf callchain data?
On 8/26/12 9:10 AM, Peter Zijlstra wrote:
On Fri, 2012-08-24 at 15:13 -0700, Arun Sharma wrote:
One option is to support
this for user mode only, with code to detect signal frames. Any other
ideas?
I guess we'd need to see what that patch would look like... :-)
It used to look
Some of our language runtimes like to map IP addresses in perf backtrace
to specific byte codes. The way things stand now, the addresses on the
backtrace are return addresses, rather than the caller. I think this
issue may be present for other unusual call/return sequences where the
user may be
On 8/8/12 12:16 PM, Arun Sharma wrote:
and therefore breaks the invariant period == period_self
in the default mode (no sort inclusive).
hist_entry__decay() also needs an update to maintain the invariant.
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -138,6 +138,7
On 3/30/12 10:43 PM, Arun Sharma wrote:
[ Meant to include v6 ChangeLog as well. Technical difficulties.. ]
v6 ChangeLog:
rebased to tip:perf/core and fixed a minor problem in computing
the total period in hists__remove_entry_filter(). Needed to
use period_self instead of period.
This patch
22 matches
Mail list logo
