Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753323AbdDKSvL (ORCPT ); Tue, 11 Apr 2017 14:51:11 -0400 Received: from mga02.intel.com ([134.134.136.20]:17839 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753258AbdDKSvJ (ORCPT ); Tue, 11 Apr 2017 14:51:09 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,186,1488873600"; d="scan'208";a="76272266" Date: Tue, 11 Apr 2017 11:51:16 -0700 (PDT) From: Shivappa Vikas X-X-Sender: vikas@vshiva-Udesk To: Thomas Gleixner cc: "Luck, Tony" , Vikas Shivappa , vikas.shivappa@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org, peterz@infradead.org, ravi.v.shankar@intel.com, fenghua.yu@intel.com, h.peter.anvin@intel.com Subject: Re: [PATCH 1/3] x86/intel_rdt: Fix issue when mkdir uses a freed CLOSid In-Reply-To: Message-ID: References: <1491255857-17213-1-git-send-email-vikas.shivappa@linux.intel.com> <1491255857-17213-2-git-send-email-vikas.shivappa@linux.intel.com> <20170405180737.GA4850@intel.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1291 Lines: 42 On Mon, 10 Apr 2017, Thomas Gleixner wrote: > On Wed, 5 Apr 2017, Luck, Tony wrote: >> On Wed, Apr 05, 2017 at 05:20:24PM +0200, Thomas Gleixner wrote: >>> That's just wrong. >>> >>> The proper behaviour for a new control group is, that at the time when it >>> is created it copies the CBM values of the default group and not claiming >>> access to ALL of the cache by default. >> >> I don't see that as any more helpful. When you make a new >> control group it is because none of the existing groups >> provides the QoS that you want. So the first thing the >> user will do is write the schemata file with the values >> they do want. >> >> So "all access", or "same as default group" are both the >> same to the user ... not what they want. >> >> We do need to make sure that the schemata matches what is >> in the registers. We need to make sure that changes to the >> schemata file result in the MSRs being written where needed. > > That's true today. The MSRs and the schemata file of a newly created group > always match. So there's nothing to fix, right? Yes. Upstream patch has the MSRs matching with what schemata shows. we can drop this patch. I sent a new MBA version without this just on the tip which has the other two patches. Thanks, Vikas > > Thanks, > > tglx > > >