Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754035AbbHDSuS (ORCPT ); Tue, 4 Aug 2015 14:50:18 -0400 Received: from mga01.intel.com ([192.55.52.88]:12847 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752391AbbHDSuQ (ORCPT ); Tue, 4 Aug 2015 14:50:16 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,610,1432623600"; d="scan'208";a="761881136" Date: Tue, 4 Aug 2015 11:50:16 -0700 (PDT) From: Vikas Shivappa X-X-Sender: vikas@vshiva-Udesk To: Tejun Heo cc: Vikas Shivappa , Vikas Shivappa , linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com, tglx@linutronix.de, mingo@kernel.org, peterz@infradead.org, matt.fleming@intel.com, will.auld@intel.com, glenn.p.williamson@intel.com, kanaka.d.juvva@intel.com Subject: Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management In-Reply-To: <20150802163157.GB32599@mtj.duckdns.org> Message-ID: References: <1435789270-27010-1-git-send-email-vikas.shivappa@linux.intel.com> <1435789270-27010-6-git-send-email-vikas.shivappa@linux.intel.com> <20150730194458.GD3504@mtj.duckdns.org> <20150802163157.GB32599@mtj.duckdns.org> 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: 2599 Lines: 65 Hello Tejun, On Sun, 2 Aug 2015, Tejun Heo wrote: > Hello, Vikas. > > On Fri, Jul 31, 2015 at 09:24:58AM -0700, Vikas Shivappa wrote: >> Yes today we dont have an alternative interface - but we can always build >> one. We simply dont have it because till now Linux kernel just tolerated the >> degradation that could have occured by cache contention and this is the >> first interface we are building. > > But we're doing it the wrong way around. You can do most of what > cgroup interface can do with systemcall-like interface with some > inconvenience. The other way doesn't really work. As I wrote in the > other reply, cgroups is a horrible programmable interface and we don't > want individual applications to interact with it directly and CAT's > use cases most definitely include each application programming its own > cache mask. I will make this more clear in the documentation - We intend this cgroup interface to be used by a root or superuser - more like a system administrator being able to control the allocation of the threads , the one who has the knowledge of the usage and being able to decide. There is already a lot of such usage among different enterprise users at Intel/google/cisco etc who have been testing the patches posted to lkml and academically there is plenty of usage as well. As a quick ref : below is a quick summary of usage Cache Allocation Technology provides a way for the Software (OS/VMM) to restrict cache allocation to a defined 'subset' of cache which may be overlapping with other 'subsets'. This feature is used when allocating a line in cache ie when pulling new data into the cache. - The tasks are grouped into CLOS (class of service). or grouped into a administrator created cgroup. - Then OS uses MSR writes to indicate the CLOSid of the thread when scheduling in (this is done by kernel) and to indicate the cache capacity associated with the CLOSid (the root user indicates the capacity for each task). Currently cache allocation is supported for L3 cache. More information can be found in the Intel SDM June 2015, Volume 3, section 17.16. Thanks, Vikas Let's build something which is simple and can be used > easily first. If this turns out to be widely useful and an overall > management capability over it is wanted, we can consider cgroups then. > > Thanks. > > -- > tejun > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/