From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030432AbbKDP27 (ORCPT ); Wed, 4 Nov 2015 10:28:59 -0500 Received: from www.linutronix.de ([62.245.132.108]:50262 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030388AbbKDP26 (ORCPT ); Wed, 4 Nov 2015 10:28:58 -0500 Date: Wed, 4 Nov 2015 16:28:04 +0100 (CET) From: Thomas Gleixner To: Luiz Capitulino cc: Fenghua Yu , H Peter Anvin , Ingo Molnar , Peter Zijlstra , linux-kernel , x86 , Vikas Shivappa , Marcelo Tosatti , tj@kernel.org, riel@redhat.com Subject: Re: [PATCH V15 00/11] x86: Intel Cache Allocation Technology Support In-Reply-To: <20151104101233.3cc79e15@redhat.com> Message-ID: References: <1443766185-61618-1-git-send-email-fenghua.yu@intel.com> <20151104094227.5aafdf2c@redhat.com> <20151104101233.3cc79e15@redhat.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Nov 2015, Luiz Capitulino wrote: > On Wed, 4 Nov 2015 15:57:41 +0100 (CET) > Thomas Gleixner wrote: > > > On Wed, 4 Nov 2015, Luiz Capitulino wrote: > > > > > On Thu, 1 Oct 2015 23:09:34 -0700 > > > Fenghua Yu wrote: > > > > > > > This series has some preparatory patches and Intel cache allocation > > > > support. > > > > > > Ping? What's the status of this series? > > > > We still need to agree on the user space interface which is the > > hardest part of it.... > > My understanding is that two interfaces have been proposed: the cgroups > one and an API based on syscalls or ioctls. > > Are those proposals mutual exclusive? What about having the cgroups one > merged IFF it's useful, and having the syscall API later if really > needed? > > I don't want to make the wrong decision, but the cgroups interface is > here. Holding it while we discuss a perfect interface that doesn't > even exist will just do a bad service for users. Well, no. We do not just introduce a random user space ABI simply because we have to support it forever. Thanks, tglx