[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141029110042.GA12099@gmail.com>
Date: Wed, 29 Oct 2014 12:00:42 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andi Kleen <ak@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andi Kleen <andi@...stfloor.org>, eranian@...gle.com,
dzickus@...hat.com, jmario@...hat.com, acme@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] Attempt to cleanup the HSW offcore bits
* Thomas Gleixner <tglx@...utronix.de> wrote:
> Andi,
>
> On Mon, 27 Oct 2014, Andi Kleen wrote:
> > On Mon, Oct 27, 2014 at 02:07:12PM +0100, Peter Zijlstra wrote:
> > > 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
> >
> > https://download.01.org/perfmon/HSW/Haswell_matrix_V14.json
> > https://download.01.org/perfmon/HSW/Haswell_matrix_bit_definitions_V14.json
>
> Of course you did not answer any of the other legitimate
> questions Peter brought up.
>
> Care to answer them w/o pointing to magic json files which lack
> ANY useful information about the magic bits they provide? And
> why they are not consistent with the SDM?
>
> Either you come forth with reasonable explanations or I'm going
> to rip out the mess you created even before Peter can persuade
> himself to do so.
So I waited a week in the hope that all this can be resolved
quickly, but the problem is that we are already at -rc3 and we
are running out of time and I'm not seeing constructive behavior
from Andi.
So I've done a straightforward revert of the messy Broadwell
client driver changes, to bring us back to the v3.17 baseline:
1776b10627e4 ("perf/x86/intel: Revert incomplete and undocumented Broadwell client support")
Andi, please rework the series on top of that and also
proactively integrate the cleanups, requests and observations
from Thomas Gleixner and Peter Zijlstra. Only submit a new series
once all feedback given to you in the past has been addressed to
the fullest!
If the patches are fixed quickly enough then we might be able to
merge support in v3.19. If not then it has to wait until v3.20 or
later kernels.
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/
Powered by blists - more mailing lists