linux-kernel - Re: [PATCH 04/12] perf, x86: Support the TSX intx/intx

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

Date:	Mon, 28 Jan 2013 11:47:18 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org, acme@...hat.com,
	eranian@...gle.com, jolsa@...hat.com, namhyung@...nel.org,
	Andi Kleen <ak@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 04/12] perf, x86: Support the TSX intx/intx_cp qualifiers
 v2

* Andi Kleen <andi@...stfloor.org> wrote:

> [dropping linux-kernel]

(Re-added, because this concerns others as well.)

> > So please re-send a truly minimal hw-enabling series first, 
> > as requested - a minimal series that enables most of the 
> > everyday usecases.
> 
> I don't have much interesting in arguing what is fundamental 
> and what is not. Variants of this patchkit have been used for 
> over a year to do Haswell work, and I have a reasonably large 
> user base for it both internal in Intel and with some other 
> Haswell users.
> 
> They need all these features. [...]

That argument is silly, dishonest and misleading: the majority 
of perf users don't *ever* specify a different profiling event 
from the default 'cycles' one, let alone do they specify CPU 
specific features - full stop.

They are using 'perf record/report', 'perf top', or use other 
tools like SysProf (that use perf 'cycles' events internally by 
default) and that's it.

A select few know about 'cycles:pp', perhaps. (In fact we'll 
make that the default in the future, to make profiling even 
easier by default.) Some do -g call-graph profiling.

Most developers that use profiling tools want to know where the 
silliest overhead in their app is and they don't care much about 
CPU specific events.

That group of users includes most kernel developers in fact: 
I've rarely seen people go beyond perf record / perf top - and 
that's *good* in a sense, because it means they get what they 
want from our primary source of profiling information already.

Things like cachemiss profiling or multi-event profiling are a 
distant second in terms of popularity. The use of CPU specific 
events is even rarer.

Any Haswell-specific features are a second or third order 
concern, at best, in terms of installed base. We *do* care about 
those usecases as well, but you are wasting precious 
hw-enablement time by insisting on more complex patches while 
stonewalling my request for the simplest ones - the minimal 
patches really belong upstream.

So please send a minimal series that serves the overwhelmingly 
common case, without any other distractions, and after that we 
can argue Haswell specific extensions to profiling.

This isn't such a difficult or in any way controversial concept 
really...

Thanks,

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