From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753817AbbB0MM2 (ORCPT ); Fri, 27 Feb 2015 07:12:28 -0500 Received: from mail-qc0-f176.google.com ([209.85.216.176]:44877 "EHLO mail-qc0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751899AbbB0MM0 (ORCPT ); Fri, 27 Feb 2015 07:12:26 -0500 Date: Fri, 27 Feb 2015 07:12:22 -0500 From: Tejun Heo To: Vikas Shivappa Cc: linux-kernel@vger.kernel.org, vikas.shivappa@intel.com, 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 Message-ID: <20150227121222.GE3964@htj.duckdns.org> References: <1424819804-4082-1-git-send-email-vikas.shivappa@linux.intel.com> <1424819804-4082-4-git-send-email-vikas.shivappa@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424819804-4082-4-git-send-email-vikas.shivappa@linux.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 Hello, On Tue, Feb 24, 2015 at 03:16:40PM -0800, Vikas Shivappa wrote: > Add support for cache bit mask manipulation. The change adds a file to > the RDT cgroup which represents the CBM(cache bit mask) for the cgroup. > > The RDT cgroup follows cgroup hierarchy ,mkdir and adding tasks to the > cgroup never fails. When a child cgroup is created it inherits the > CLOSid and the CBM from its parent. When a user changes the default > CBM for a cgroup, a new CLOSid may be allocated if the CBM was not > used before. If the new CBM is the one that is already used, the > count for that CLOSid<->CBM is incremented. The changing of 'cbm' > may fail with -ENOSPC once the kernel runs out of maximum CLOSids it > can support. > User can create as many cgroups as he wants but having different CBMs > at the same time is restricted by the maximum number of CLOSids > (multiple cgroups can have the same CBM). > Kernel maintains a CLOSid<->cbm mapping which keeps count > of cgroups using a CLOSid. > > The tasks in the CAT cgroup would get to fill the LLC cache represented > by the cgroup's 'cbm' file. > > Reuse of CLOSids for cgroups with same bitmask also has following > advantages: > - This helps to use the scant CLOSids optimally. > - This also implies that during context switch, write to PQR-MSR is done > only when a task with a different bitmask is scheduled in. I feel a bit underwhelmed about this new controller and its interface. It is evidently at a lot lower level and way more niche than what other controllers are doing, even cpuset. At the same time, as long as it's well isolated, it piggybacking on cgroup should be okay. I take it that the feature implemented is too coarse to allow for weight based distribution? Thanks. -- tejun