From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755485AbbB0Vk1 (ORCPT ); Fri, 27 Feb 2015 16:40:27 -0500 Received: from mga14.intel.com ([192.55.52.115]:2957 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753539AbbB0Vk0 (ORCPT ); Fri, 27 Feb 2015 16:40:26 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,662,1418112000"; d="scan'208";a="460435783" Date: Fri, 27 Feb 2015 13:38:41 -0800 (PST) From: Vikas Shivappa X-X-Sender: vikas@vshiva-Udesk To: Tejun Heo cc: Vikas Shivappa , Vikas Shivappa , linux-kernel@vger.kernel.org, matt.fleming@intel.com, hpa@zytor.com, tglx@linutronix.de, mingo@kernel.org, peterz@infradead.org, will.auld@intel.com, dave.hansen@intel.com, andi.kleen@intel.com, tony.luck@intel.com, kanaka.d.juvva@intel.com Subject: Re: [PATCH 3/7] x86/intel_rdt: Support cache bit mask for Intel CAT In-Reply-To: <20150227194204.GP3964@htj.duckdns.org> Message-ID: References: <1424819804-4082-1-git-send-email-vikas.shivappa@linux.intel.com> <1424819804-4082-4-git-send-email-vikas.shivappa@linux.intel.com> <20150227121222.GE3964@htj.duckdns.org> <20150227194204.GP3964@htj.duckdns.org> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 27 Feb 2015, Tejun Heo wrote: > Hello, Vikas. > > On Fri, Feb 27, 2015 at 11:34:16AM -0800, Vikas Shivappa wrote: >> This cgroup subsystem would basically let the user partition one of the >> Platform shared resource , the LLC cache. This could be extended in future > > I suppose LLC means last level cache? It'd be great if you can spell > out the full term when the abbreviation is first referenced in the > comments or documentation. > Yes that's last level cache. Will update documentation/comments if any. >> to partition more shared resources when there is hardware support that way >> we may eventually have more files in the cgroup. RDT is a generic term for >> platform resource sharing. > >> For more information you can refer to section 17.15 of Intel SDM. >> We did go through quite a bit of discussion on lkml regarding adding the >> cgroup interface for CAT and the patches were posted only after that. >> This cgroup would not interact with other cgroups in the sense would not >> modify or add any elements to existing cgroups - there was such a proposal >> but was removed as we did not get agreement on lkml. >> >> the original lkml thread is here from 10/2014 for your reference - >> https://lkml.org/lkml/2014/10/16/568 > > Yeap, I followed that thread and this being a separate controller > definitely makes a lot more sense. > >> I >>> take it that the feature implemented is too coarse to allow for weight >>> based distribution? >>> >> Could you please clarify more on this ? However there is a limitation from >> hardware that there have to be a minimum of 2 bits in the cbm if thats what >> you referred to. Otherwise the bits in the cbm directly map to the number of >> cache ways and hence the cache capacity .. > > Right, so the granularity is fairly coarse and specifying things like > "distribute cache in 4:2:1 (or even in absolute bytes) to these three > cgroups" wouldn't work at all. Specifying in any amount of cache bytes would be not possible because the minimum granularity has to be atleast one cache way because the entire memory can be indexed into one cache way. Providing the bit mask granularity helps users to not worry about how much bytes cache way is and can specify in terms of the bitmask. If we want to provide such an interface in the cgroups where users can specify the size in bytes then we need to show the user the minimum granularity in bytes as well. Also note that this bit masks are overlapping and hence the users have a way to specify overlapped regions in cache which may be very useful in lot of scenarios where multiple cgroups want to share the capacity. The minimum granularity is 2 bits in the pre-production SKUs and it does put limitation to scenarios you say. We will issue a patch update once it hopefully gets updated in later SKUs. But note that the SDM also recommends using 2 bits from performance aspect because an application using only cache-way would have a lot more conflicts. Say if max cbm is 20bits then the granularity is 10% of total cache.. > > Thanks. > > -- > tejun >