[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201019010026.x72tmoqv6uh76ene@two.firstfloor.org>
Date: Sun, 18 Oct 2020 18:00:27 -0700
From: Andi Kleen <andi@...stfloor.org>
To: Or Gerlitz <gerlitz.or@...il.com>
Cc: Andi Kleen <andi@...stfloor.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Brendan Gregg <bgregg@...flix.com>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: perf measure for stalled cycles per instruction on newer Intel
processors
> > Don't use it. It's misleading on a out-of-order CPU because you don't
> > know if it's actually limiting anything.
> >
> > If you want useful bottleneck data use --topdown.
>
> So running again, this time with the below params, I got this output
> where all the right most column is colored red. I wonder what can be
> said on the amount/ratio of stalls for this app - if you can maybe recommend
> some posts of yours to better understand that, I saw some comment in the
> perf-stat man page and some lwn article but wasn't really able to figure it out.
TopDown determines what limits the execution the most.
The application is mostly backend bound (55-72%). This can be either memory
issues (more common), or sometimes also execution issues. Standard perf
doesn't support a further break down beyond these high level categories,
but there are alternative tools that do (e.g. mine is "toplev" in
https://github.com/andikleen/pmu-tools or VTune)
Some references on TopDown:
https://github.com/andikleen/pmu-tools/wiki/toplev-manual
http://bit.ly/tma-ispass14
The tools above would also allow you to sample where the stalls
are occuring.
-Andi
Powered by blists - more mailing lists