From: Peter Zijlstra <peterz@infradead.org>
To: christophe leroy <christophe.leroy@c-s.fr>
Cc: Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: perf events: how to implement TLB misses as SW event ?
Date: Wed, 27 Nov 2013 12:43:54 +0100 [thread overview]
Message-ID: <20131127114354.GZ10022@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <52924132.2080209@c-s.fr>
On Sun, Nov 24, 2013 at 07:10:58PM +0100, christophe leroy wrote:
> Today in the perfevents subsystem it looks like DTLB/ITLB misses are
> implemented as HW counter only.
> On some processors, like PowerPC 8xx, there is no counter for that. However
> DTLB/ITLB misses are handled as exceptions via software, so we have an
> opportunity to implement a SW counter for that.
> What's the easiest/best way to implement it ?
The very easiest way would be to place a trace_event in your tlb miss
handler.
_HOWEVER_ I suspect you're quite limited in what you can do from an
actual tlb miss handler -- seeing as generating another miss from a
miss-handler might be a bad thing.
So I suspect that'll not actually work.
You'll need to educate me a bit on what you can (and can not) do from a
tlb miss handler on your platforms.
I'm assuming you have a limited fixed memory map to work from while in
the tlb fault handler -- you need something like that for such a handler
to run.
So one possible option would be to keep a free-running counter in
whatever fixed mapped memory region you have, and read from that. This
would allow you to implement a non-sampling software pmu for these
events.
If you have means of raising an interrupt; or other means of causing
some routine to run in a 'normal' context. You could implement a more
complete counter.
For example, you could decrement your fixed map counter on each tlb
miss, and when it hits 0, write some state -- eg. the instruction
pointer of the instruction that caused the tlb miss -- into a related
field in the fixed map and raise the interrupt.
You can then use this mechanism from either your hardware pmu driver or
a separate pmu implementation as a 'regular' fixed purpose counter.
Since its all software, you can even implement whatever filters your
hardware counters have to match its capabilities.
prev parent reply other threads:[~2013-11-27 11:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-24 18:10 perf events: how to implement TLB misses as SW event ? christophe leroy
2013-11-27 11:43 ` Peter Zijlstra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131127114354.GZ10022@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@ghostprotocols.net \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox