Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932068AbbHDShE (ORCPT ); Tue, 4 Aug 2015 14:37:04 -0400 Received: from mail-yk0-f173.google.com ([209.85.160.173]:34190 "EHLO mail-yk0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752803AbbHDShC (ORCPT ); Tue, 4 Aug 2015 14:37:02 -0400 Date: Tue, 4 Aug 2015 14:36:59 -0400 From: Tejun Heo To: Marcelo Tosatti Cc: Vikas Shivappa , linux-kernel@vger.kernel.org, vikas.shivappa@intel.com, 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: <20150804183659.GG17598@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> <20150731151218.GC22948@amt.cnet> <20150802162325.GA32599@mtj.duckdns.org> <20150803203250.GA31668@amt.cnet> <20150804125520.GA31450@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150804125520.GA31450@amt.cnet> 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 Content-Length: 1170 Lines: 28 Hello, On Tue, Aug 04, 2015 at 09:55:20AM -0300, Marcelo Tosatti wrote: ... > Can't "cacheset" helper (similar to taskset) talk to systemd > to achieve the flexibility you point ? I don't know. This is the case in point. You're now suggesting doing things completely backwards - a thread of an application talking to external agent to tweak system management interface so that it can change the attribute of that thread. Let's please build a programmable interface first. I'm sure there are use cases which aren't gonna be covered 100% but at the same time I'm sure just simple inheritable per-thread attribute would cover majority of use cases. This really isn't that different from CPU affinity after all. *If* it turns out that a lot of people yearn for fully hierarchical enforcement, we sure can do that in the future but at this point it really looks like an overkill in the wrong direction. 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/