[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1011051000310.26020@cl320.eecs.utk.edu>
Date: Fri, 5 Nov 2010 10:02:01 -0400 (EDT)
From: Vince Weaver <vweaver1@...s.utk.edu>
To: Francis Moreau <francis.moro@...il.com>
cc: Victor Jimenez <victor.javier@....es>,
Reid Kleckner <reid.kleckner@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Stephane Eranian <eranian@...gle.com>,
linux-perf-users@...r.kernel.org
Subject: Re: perf tools miscellaneous questions
On Fri, 5 Nov 2010, Francis Moreau wrote:
> Victor Jimenez <victor.javier@....es> writes:
>
> [...]
>
> > If you are measuring last level cache misses, I would recommend you to
> > use a memory intensive application/benchmark instead of /bin/true, as
> > otherwise there can be a significant variation between two runs.
>
> I agree.
>
> But still with intensive application, I got the same results:
you're going to need to get your architectural manual for your processor
and use raw events (not the kernel default ones) if you really want to
find out what's going on. A tool like libpfm4 can help change the names
to raw events for you.
Cache events are very tricky and they often don't return the values you
expect. Hardware prefetch can cause some very non-intuitive things to
happen, and the prefetch only affects certain levels of cache.
Vince
--
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