public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: a.p.zijlstra@chello.nl, akpm@linux-foundation.org,
	acme@redhat.com, eranian@google.com, jolsa@redhat.com,
	namhyung@kernel.org, Andi Kleen <ak@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 04/12] perf, x86: Support the TSX intx/intx_cp qualifiers v2
Date: Mon, 28 Jan 2013 11:47:18 +0100	[thread overview]
Message-ID: <20130128104718.GB20263@gmail.com> (raw)
In-Reply-To: <20130128050234.GQ30577@one.firstfloor.org>


* Andi Kleen <andi@firstfloor.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

  parent reply	other threads:[~2013-01-28 10:47 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25 22:00 Basic perf PMU support for Haswell v1 Andi Kleen
2013-01-25 22:00 ` [PATCH 01/12] perf, x86: Add PEBSv2 record support Andi Kleen
2013-01-28 13:15   ` Stephane Eranian
2013-01-28 16:10     ` Andi Kleen
2013-01-31 17:15   ` Stephane Eranian
2013-01-25 22:00 ` [PATCH 02/12] perf, x86: Basic Haswell PMU support v2 Andi Kleen
2013-01-28 15:34   ` Stephane Eranian
2013-01-28 16:16     ` Andi Kleen
2013-01-25 22:00 ` [PATCH 03/12] perf, x86: Basic Haswell PEBS support v3 Andi Kleen
2013-01-28 15:56   ` Stephane Eranian
2013-01-25 22:00 ` [PATCH 04/12] perf, x86: Support the TSX intx/intx_cp qualifiers v2 Andi Kleen
2013-01-26 11:54   ` Ingo Molnar
2013-01-26 21:00     ` Andi Kleen
2013-01-27 13:14       ` Ingo Molnar
     [not found]         ` <20130128050234.GQ30577@one.firstfloor.org>
2013-01-28 10:47           ` Ingo Molnar [this message]
2013-01-28 16:52   ` Stephane Eranian
2013-01-28 17:37     ` Andi Kleen
2013-01-25 22:00 ` [PATCH 05/12] perf, x86: Support Haswell v4 LBR format Andi Kleen
2013-01-28 21:47   ` Stephane Eranian
2013-01-28 22:08     ` Andi Kleen
2013-01-28 22:20       ` Stephane Eranian
2013-01-25 22:00 ` [PATCH 06/12] perf, x86: Support full width counting Andi Kleen
2013-01-25 22:00 ` [PATCH 07/12] perf, x86: Avoid checkpointed counters causing excessive TSX aborts v3 Andi Kleen
2013-01-28 22:32   ` Stephane Eranian
2013-01-28 23:16     ` Andi Kleen
2013-01-29  0:30       ` Stephane Eranian
2013-01-29  1:00         ` Andi Kleen
2013-01-30  8:51           ` Stephane Eranian
2013-01-30 20:58             ` Andi Kleen
2013-01-25 22:00 ` [PATCH 08/12] perf, x86: Move NMI clearing to end of PMI handler after the counter registers are reset Andi Kleen
2013-01-25 22:00 ` [PATCH 09/12] perf, x86: Disable LBR recording for unknown LBR_FMT Andi Kleen
2013-01-25 22:00 ` [PATCH 10/12] perf, x86: Support LBR filtering by INTX/NOTX/ABORT v2 Andi Kleen
2013-01-25 22:00 ` [PATCH 11/12] perf, tools: Support sorting by intx, abort branch flags v2 Andi Kleen
2013-01-25 22:00 ` [PATCH 12/12] perf, tools: Add abort_tx,no_tx,in_tx branch filter options to perf record -j v3 Andi Kleen
2013-01-31 17:19 ` Basic perf PMU support for Haswell v1 Stephane Eranian
2013-01-31 17:47   ` Andi Kleen

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=20130128104718.GB20263@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=torvalds@linux-foundation.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