From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965264AbbJVJZZ (ORCPT ); Thu, 22 Oct 2015 05:25:25 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:35490 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964918AbbJVJZN (ORCPT ); Thu, 22 Oct 2015 05:25:13 -0400 Date: Thu, 22 Oct 2015 11:25:08 +0200 From: Ingo Molnar To: Andi Kleen Cc: Peter Zijlstra , Andi Kleen , linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Thomas Gleixner Subject: Re: [PATCH 1/3] x86, perf: Use a new PMU ack sequence Message-ID: <20151022092508.GA21192@gmail.com> References: <1445458568-16956-1-git-send-email-andi@firstfloor.org> <20151021203621.GJ2508@worktop.programming.kicks-ass.net> <20151021214638.GH15102@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151021214638.GH15102@tassilo.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andi Kleen wrote: > > > v2: > > > Use new ack sequence unconditionally. Remove pmu reset code. > > > > So this is not something we can easily revert if things go bad. Esp. > > since you build on it with the next patches. > > Ok, and? Sigh, you are being disruptive again. > You want me to go back to the previous patch? That one is easily > undoable (just disable the flag for the model) > > Another alternative would be to fork the PMI handler into a new and > an old version, that is switchable. Here you pretend that you didn't read the sane solution that was suggested to you just three days ago: http://lkml.kernel.org/r/20151019070812.GB17855@gmail.com " > > Ingo, do you want to first merge the safe patch and then clean up? > > Yeah, would be nice to structure it that way, out of general paranoia. " I.e. first apply the safe approach, then, after the dependent changes, clean it up by introducing the dangerous change. The thing is, I'm close to summarily NAK-ing any patches from you to the perf subsystem, due to the unacceptably low quality patches combined with obtuse passive-aggressive obstruction you are routinely burdening maintainers with. Btw., I noticed that you routinely don't Cc me to perf patches. Please always Cc: me to perf patches (both kernel and tooling patches). I still will not apply them directly, only if another perf maintainer signs off on them, but I'd like to have a record of all your submissions. Thanks, Ingo