linux-kernel - Re: perf events: how to implement TLB misses as SW event ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 27 Nov 2013 12:43:54 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	christophe leroy <christophe.leroy@....fr>
Cc:	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: perf events: how to implement TLB misses as SW event ?

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.
--
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/