Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2129511imm; Sat, 29 Sep 2018 11:00:02 -0700 (PDT) X-Google-Smtp-Source: ACcGV61FSSNy7pWV9qG5o+fAXdGs1WJOOhYiMkVy+Ry7kQdiIRej1Sm7F1FcM+pXiO9LDO+3S9Zx X-Received: by 2002:a17:902:b212:: with SMTP id t18-v6mr4204279plr.136.1538244002631; Sat, 29 Sep 2018 11:00:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538244002; cv=none; d=google.com; s=arc-20160816; b=uXSbHwEdM/ltKqvVdqQ26gXqiwmusmR0PPuzz7WrzUQse5tlpVEQi5DROJVmRIsb6y mQ7UqwY62QECCINHXpCViL7yTisAwRSReOuiALwH28KQW8SJCAJjrPNusRij4GD11KNs qBtzZi4MJskjhKLhRjIc7C/zXTRjIJDyTzECBDqapwosVNqN5f8Zl+ZibNl0jAVVp9Em BkPdKlKAfeEitDg/3u1vEIV3GKD+ew6ct8mRNxTjGClkuNxad638NhsgdpvAIc9VMuje NMu+UMh2/nn+/kO65h4hK+6T97U8ur1it8fOFvi8GfPBPdjOb2bxxJHfk7GyJkwriU1S xv9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=ITevvbuCkyl1v0ei46hf648X7lbDVl+OqM02kLEqGMM=; b=YNOcxQZU5kMgQ8F1PSyo9vi31InUCZoo4KShWgpZ8mv+BnxQwmQmQ8xIaKnO7HOPPA VKpRGK39Q+YFGIXXZVpdB24AZ8V3OLRBWGZdRoSI1VVPaQNDVKoMRCBD1U7tDlMDj4Za cOKYrZULMj6sd+BhLkOnsjmWG+RErhEC+N2xFmEbqGeHMJv3GA6gbtyK0rzl6cvpn9GL pv2l183L9x3Y8geII9B9mzSwxLe7N0cgKF6cVQnOeEPQcsGd0Zs4Es77bqxpXkWCz7Cx KiXdhMjdJydfsJjN9V97EKxX99JbYJiI3iab5CoLC2ERHFMtxyV93Vgk9eaad5MRzOlQ zHUw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b129-v6si8135977pfa.12.2018.09.29.10.59.33; Sat, 29 Sep 2018 11:00:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728518AbeI3A0O (ORCPT + 99 others); Sat, 29 Sep 2018 20:26:14 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:55834 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728462AbeI3A0O (ORCPT ); Sat, 29 Sep 2018 20:26:14 -0400 Received: from p5492e4c1.dip0.t-ipconnect.de ([84.146.228.193] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g6JTh-0006Wn-KE; Sat, 29 Sep 2018 19:56:30 +0200 Date: Sat, 29 Sep 2018 19:56:28 +0200 (CEST) From: Thomas Gleixner To: Reinette Chatre cc: Peter Zijlstra , fenghua.yu@intel.com, tony.luck@intel.com, mingo@redhat.com, acme@kernel.org, gavin.hindman@intel.com, jithu.joseph@intel.com, dave.hansen@intel.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V5 0/6] perf and x86/intel_rdt: Fix lack of coordination with perf In-Reply-To: <42c2b375-dbb9-11a3-8e2f-bec744e73b10@intel.com> Message-ID: References: <20180920141150.GY24124@hirez.programming.kicks-ass.net> <77383a1e-f343-7529-24cf-874f0999507d@intel.com> <20180928065830.GE3439@hirez.programming.kicks-ass.net> <42c2b375-dbb9-11a3-8e2f-bec744e73b10@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Reinette, On Sat, 29 Sep 2018, Reinette Chatre wrote: > I interpreted Thomas and Peter's responses to mean that there are no > objections for this to be included in v4.19 as a fix. > > If I understand the tip branches correctly the core patch seems to be > headed to v4.19 while the rest (excluding the final patch > "x86/intel_rdt: Re-enable pseudo-lock measurements") are headed to v4.20. > > Have you decided against including this into v4.19 or did I > misunderstand the responses and/or branches? I did not decide anything yet. It's not going into -rc6 as it's not yet through next and the other standard testing. I'm also looking at the other set of RDT fixes, which obviously want to go as well. So not sure how to deal with all of that. Thanks, tglx