linux-kernel - Re: [RFC 0/5] CR4 handling improvements

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Oct 2014 13:05:49 -0400 (EDT)
From:	Vince Weaver <vince@...ter.net>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Andy Lutomirski <luto@...capital.net>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Erik Bosman <ebn310@....vu.nl>
Subject: Re: [RFC 0/5] CR4 handling improvements

On Tue, 21 Oct 2014, Peter Zijlstra wrote:

> > perf_event is also fairly high overhead for setting up and starting 
> > events,
> 
> Which you only do once at the start, so is that really a problem?

There are various reasons why you might want to start events at times
other than the beginning of the program.  Some people don't like kernel 
multiplexing so they start/stop manually if they want to switch eventsets.

But no, I suppose you could ask anyone wanting to use rdpmc to open some 
sort of dummy event at startup just to get cr4 enabled.

> I still don't get that argument, 2 rdpmc's is cheaper than doing wrmsr,
> not to mention doing wrmsr through a syscall. And looking at that mmap
> page is 1 cacheline. Is that cacheline read (assuming you miss) the real
> problem?

Well at least by default the first read of the mmap page causes a 
pagefault which adds a few thousand cycles of latency.  Though you can
somewhat get around this by prefaulting it in at some point.

Anyway I'm just reporting numbers I get when measuring the overhead of 
the old perfctr interface vs perf_event on typical PAPI workloads.  It's 
true you can re-arrange calls and such so that perf_event behaves better 
but that involves redoing a lot of existing code.

I do appreciate the trouble you've gone through keeping self-monitoring 
working considering the fact that I'm the only user admitting to using it.

Adding perf_event rdpmc support to PAPI has been stalled for a while due 
to various reasons.  So that's why I haven't been finding the various bugs 
that have been turning up.  The PAPI perf_event component really needs a 
complete from-scratch re-write, but that's made tricky because we have to 
be backwards compatible and workaround all the pre-2.6.36 perf_event bugs.
You wouldn't think anyone would care, but the most vocal users are all 
RHEL 6 users running the monstrosity of a 2.6.32 kernel that is patched 
full of all kinds of crazy back-ported perf_event patches, and that is 
always breaking PAPI in fun and exciting ways.

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/