From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753772AbbHEQKk (ORCPT ); Wed, 5 Aug 2015 12:10:40 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:36325 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752622AbbHEQKg (ORCPT ); Wed, 5 Aug 2015 12:10:36 -0400 Date: Wed, 5 Aug 2015 12:10:29 -0400 From: Tejun Heo To: Matt Fleming 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 Message-ID: <20150805161029.GM17598@mtj.duckdns.org> 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> <20150805122257.GD4332@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150805122257.GD4332@codeblueprint.co.uk> 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 Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote: > I wager that this assertion is wrong. Having individual applications > program their own cache mask is not going to be the most common > scenario. Only in very specific situations would you trust an > application to do that. As I wrote in the other reply, I don't buy that. The above only holds if you exclude use cases where this feature is used by multiple threads of an application and I can't see a single reason why such uses would be excluded. > A much more likely use case is having the sysadmin carve up the cache > for a workload which may include multiple, uncooperating applications. > > Yes, a programmable interface would be useful, but only for a limited > set of workloads. I don't think it's how most people are going to want > to use this hardware technology. It's actually the other way around. You can achieve most of what cgroups can do with programmable interface albeit with some awkwardness. The other direction is a lot more heavier and painful. Thanks. -- tejun