From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758651AbcJQUUs (ORCPT ); Mon, 17 Oct 2016 16:20:48 -0400 Received: from mga05.intel.com ([192.55.52.43]:24105 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754426AbcJQUUf (ORCPT ); Mon, 17 Oct 2016 16:20:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,358,1473145200"; d="scan'208";a="20952204" Date: Mon, 17 Oct 2016 13:20:33 -0700 From: "Luck, Tony" To: "Yu, Fenghua" Cc: Thomas Gleixner , "Anvin, H Peter" , Ingo Molnar , Peter Zijlstra , Stephane Eranian , Borislav Petkov , "Hansen, Dave" , Nilay Vaish , Shaohua Li , David Carrillo-Cisneros , "Shankar, Ravi V" , "Prakhya, Sai Praneeth" , Vikas Shivappa , linux-kernel , x86 Subject: Re: [PATCH v4 08/18] x86/intel_rdt: Pick up L3/L2 RDT parameters from CPUID Message-ID: <20161017202033.GA5142@intel.com> References: <1476497548-11169-1-git-send-email-fenghua.yu@intel.com> <1476497548-11169-9-git-send-email-fenghua.yu@intel.com> <20161017180655.GB8999@linux.intel.com> <20161017163524.GA1808@intel.com> <3E5A0FA7E9CA944F9D5414FEC6C712205E00D9C9@ORSMSX106.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5A0FA7E9CA944F9D5414FEC6C712205E00D9C9@ORSMSX106.amr.corp.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 On Mon, Oct 17, 2016 at 09:43:41AM -0700, Yu, Fenghua wrote: > > > > I wonder whether this is the proper abstraction level. We might as > > > > well do the following: > > > > > > > > rdtresources[] = { > > > > { > > > > .name = "L3", > > > > }, > > > > { > > > > .name = "L3Data", > > > > }, > > > > { > > > > .name = "L3Code", > > > > }, > > > > > > > > and enable either L3 or L3Data+L3Code. Not sure if that makes things > > > > simpler, but it's definitely worth a thought or two. > > > > > > This way will be better than having cdp_enabled/capable for L3 and not > > > for L2. And this doesn't change current userinterface design either, > > > I think. > > > > User interface would change if you did this. The schemata file would look like > > this with CDP enabled: > > > > # cat schemata > > L3Data:0=fffff;1=fffff;2=fffff;3=fffff > > L3Code:0=fffff;1=fffff;2=fffff;3=fffff > > > > but that is easier to read than the current: > > > > # cat schemata > > L3:0=fffff,fffff;1=fffff,fffff;2=fffff,fffff;3=fffff,fffff > > > > which gives you no clue on which mask is code and which is data. > > Right. > > Also changing to uniform format :=cbm1;=cbm2;... > is lot easier to parse schemata line in CDP mode. > > So I'll change the code and doc to have two new resources: L3Data and L3Code for CDP mode. Doc change (fold into part 05): diff --git a/Documentation/x86/intel_rdt_ui.txt b/Documentation/x86/intel_rdt_ui.txt index e56781952f42..b9f634c9a058 100644 --- a/Documentation/x86/intel_rdt_ui.txt +++ b/Documentation/x86/intel_rdt_ui.txt @@ -97,13 +97,18 @@ With CDP disabled the L3 schemata format is: L3 details (CDP enabled via mount option to resctrl) ---------------------------------------------------- -When CDP is enabled, you need to specify separate cache bit masks for -code and data access. The generic format is: +When CDP is enabled L3 control is split into two separate resources +so you can specify independent masks for code and data like this: - L3:=,;=,;... + L3data:=;=;... + L3code:=;=;... -where the d_cbm masks are for data access, and the i_cbm masks for code. +L2 details +---------- +L2 cache does not support code and data prioritization, so the +schemata format is always: + L2:=;=;... Example 1 ---------