public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: mingo@kernel.org, tglx@linutronix.de, ak@linux.intel.com,
	eranian@google.com, dzickus@redhat.com, jmario@redhat.com,
	acme@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] Attempt to cleanup the HSW offcore bits
Date: Mon, 27 Oct 2014 14:07:12 +0100	[thread overview]
Message-ID: <20141027130712.GF3337@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20141027122340.GU12538@two.firstfloor.org>

On Mon, Oct 27, 2014 at 01:23:40PM +0100, Andi Kleen wrote:
> On Thu, Oct 23, 2014 at 12:51:19PM +0200, Peter Zijlstra wrote:
> > So Don asked about offcore and because I forgot I looked at the code and found
> > the terrible mess Andi created with the HSW/BDW bits.
> > 
> > This series attempts to clean some of that up but seeing how it was all magic
> > numbers 
> 
> All the bits are documented. The actual definitions are available
> in the JSON offcore definitions at https://download.01.org/perfmon/

Yeah, no. That's not how we write code. Also, there's no actual JSON
offcore file for HSW only some TSV file, and I've no mind to go decode
and reverse engineer that stuff.

Also, semi unreadable files on a weird web location is not
documentation, the SDM is and the SDM does not explain why you didn't
put the PF request bits in the OP_PREFETCH events, nor why you added the
IFETCH bits to the OP_READ where all the other uarchs didn't.

Nor does it explain why you set bits 7,9 in OP_READ even though they're
listed as 'reserved'.

It also doesn't explain why you don't program a Supplier Info for
RESULT_ACCESS.

Nor why you set 0x78 in bits 23:30, which even for SNB are still listed
as reserved, even though its official offcore events have that set to
0xFF for all remote events.

And lacking SDM you should have explained all that in your Changelog,
but that's also entirely devoid of any usable information.

> > and no reasons provided for the differences with existing uarchs this
> > might just break things horribly.
> > That said, if this does break things, fixes will have to explain things, so
> > that's good.
> 
> I trust you won't submit or merge untested patches.

You trust wrong.. I should never have merged your patches, but seeing
they're in it needed cleaning up.

I can revert your patches if you'd rather have that?

  reply	other threads:[~2014-10-27 13:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-23 10:51 [PATCH 0/4] Attempt to cleanup the HSW offcore bits Peter Zijlstra
2014-10-23 10:51 ` [PATCH 1/4] perf,x86: De-obfuscate " Peter Zijlstra
2014-10-23 12:16   ` Borislav Petkov
2014-10-23 13:13     ` Peter Zijlstra
2014-10-23 10:51 ` [PATCH 2/4] perf,x86: HSW offcore prefetch events Peter Zijlstra
2014-10-23 10:51 ` [PATCH 3/4] perf,x86: Attempt to sanitize the HSW supplier info Peter Zijlstra
2014-10-23 10:51 ` [PATCH 4/4] perf,x86: Introduce HSW cache numa events Peter Zijlstra
2014-10-27 12:23 ` [PATCH 0/4] Attempt to cleanup the HSW offcore bits Andi Kleen
2014-10-27 13:07   ` Peter Zijlstra [this message]
2014-10-27 14:28     ` Andi Kleen
2014-10-27 14:48       ` Peter Zijlstra
2014-10-28 21:53       ` Thomas Gleixner
2014-10-29 11:00         ` Ingo Molnar

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=20141027130712.GF3337@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=dzickus@redhat.com \
    --cc=eranian@google.com \
    --cc=jmario@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /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