From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752241AbbJZUDK (ORCPT <rfc822;w@1wt.eu>);
	Mon, 26 Oct 2015 16:03:10 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49571 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751136AbbJZUDJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 26 Oct 2015 16:03:09 -0400
Date: Mon, 26 Oct 2015 18:02:22 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>, Fenghua Yu <fenghua.yu@intel.com>,
        H Peter Anvin <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>
Subject: Re: [PATCH V15 00/11] x86: Intel Cache Allocation Technology Support
Message-ID: <20151026200222.GA12266@amt.cnet>
References: <1443766185-61618-1-git-send-email-fenghua.yu@intel.com>
 <alpine.DEB.2.11.1510112145100.6097@nanos>
 <20151013213125.GA16200@amt.cnet>
 <20151015113614.GL3816@twins.programming.kicks-ass.net>
 <20151016022851.GA9008@amt.cnet>
 <20151016095022.GP3816@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151016095022.GP3816@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Peter,

On Fri, Oct 16, 2015 at 11:50:22AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 11:28:52PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti wrote:
> > > > I am rewriting the interface with ioctls, with commands similar to the
> > > > syscall interface proposed.
> > > 
> > > Which is horrible for other use cases. I really don't see the problem
> > > with the cgroup stuff.
> > 
> > Can you detail what "horrible" means? 
> 
> Say an RT scenario; you set up your machine with cgroups. You create a
> cpuset with is disjoint from the others, 

taskset. sys_schedsetaffinity.

> you frob around with the cpu
> cgroup, etc..
> 
> So once you're all done, you start your RT app into a cgroup.
> 
> But oh, fail, now you have to go muck about with ioctl()s to get the
> cache allocation cruft to work.

1) Its a command similar to taskset.

2) Cgroup interface as you propose seem to go against the usecase indicated by Tejun where
applications set the cache allocation themselves.

(The two points indicate that i can't see the benefit of the cgroup
interface suggestion, please clarify).