Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751985AbbLaTX2 (ORCPT ); Thu, 31 Dec 2015 14:23:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48563 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751263AbbLaTXZ (ORCPT ); Thu, 31 Dec 2015 14:23:25 -0500 Date: Thu, 31 Dec 2015 17:22:32 -0200 From: Marcelo Tosatti To: Thomas Gleixner Cc: "Yu, Fenghua" , LKML , Peter Zijlstra , "x86@kernel.org" , Luiz Capitulino , "Shivappa, Vikas" , Tejun Heo , "Shankar, Ravi V" , "Luck, Tony" Subject: Re: [RFD] CAT user space interface revisited Message-ID: <20151231192232.GA10838@amt.cnet> References: <3E5A0FA7E9CA944F9D5414FEC6C712205DF4E157@ORSMSX106.amr.corp.intel.com> <20151223102820.GA2559@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4500 Lines: 106 On Tue, Dec 29, 2015 at 01:44:16PM +0100, Thomas Gleixner wrote: > Marcelo, > > On Wed, 23 Dec 2015, Marcelo Tosatti wrote: > > On Tue, Dec 22, 2015 at 06:12:05PM +0000, Yu, Fenghua wrote: > > > > From: Thomas Gleixner [mailto:tglx@linutronix.de] > > > > > > > > I was not able to identify any existing infrastructure where this really fits in. I > > > > chose a directory/file based representation. We certainly could do the same > > > > > > Is this be /sys/devices/system/? > > > Then create qos/cat directory. In the future, other directories may be created > > > e.g. qos/mbm? > > > > I suppose Thomas is talking about the socketmask only, as discussed in > > the call with Intel. > > I have no idea about what you talked in a RH/Intel call. > > > Thomas, is that correct? (if you want a change in directory structure, > > please explain the whys, because we don't need that change in directory > > structure). > > Can you please start to write coherent and understandable mails? I have no > idea of which directory structure, which does not need to be changed, you are > talking. Thomas, There is one directory structure in this topic, CAT. That is the directory structure which is exposed to userspace to control the CAT HW. With the current patchset posted by Intel ("Subject: [PATCH V16 00/11] x86: Intel Cache Allocation Technology Support"), the directory structure there (the files and directories exposed by that patchset) (*1) does not allow one to configure different CBM masks on each socket (that is, it forces the user to configure the same mask CBM on every socket). This is a blocker for us, and it is one of the points in your proposal. There was a call between Red Hat and Intel where it was communicated to Intel, and Intel agreed, that it was necessary to fix this (fix this == allow different CBM masks on different sockets). Now, that is one change to the current directory structure (*1). (*1) modified to allow for different CBM masks on different sockets, lets say (*2), is what we have been waiting for Intel to post. It would handle our usecase, and all use-cases which the current patchset from Intel already handles (Vikas posted emails mentioning there are happy users of the current interface, feel free to ask him for more details). What i have asked you, and you replied "to go Google read my previous post" is this: What are the advantages over you proposal (which is a completely different directory structure, requiring a complete rewrite), over (*2) ? (what is my reason behind this: the reason is that if you, with maintainer veto power, forces your proposal to be accepted, it will be necessary to wait for another rewrite (a new set of problems, fully think through your proposal, test it, ...) rather than simply modify an already known, reviewed, already used directory structure. And functionally, your proposal adds nothing to (*2) (other than, well, being a different directory structure). If Fenghua or you post a patchset, say in 2 weeks, with your proposal, i am fine with that. But i since i doubt that will be the case, i am pushing for the interface which requires the least amount of changes (and therefore the least amount of time) to be integrated. >From your email: "It would even be sufficient for particular use cases to just associate a piece of cache to a given CPU and do not bother with tasks at all. We really need to make this as configurable as possible from userspace without imposing random restrictions to it. I played around with it on my new intel toy and the restriction to 16 COS ids (that's 8 with CDP enabled) makes it really useless if we force the ids to have the same meaning on all sockets and restrict it to per task partitioning." Yes, thats the issue we hit, that is the modification that was agreed with Intel, and thats what we are waiting for them to post. > I described a directory structure for that qos/cat stuff in my proposal and > that's complete AFAICT. Ok, lets make the job for the submitter easier. You are the maintainer, so you decide. Is it enough for you to have (*2) (which was agreed with Intel), or would you rather prefer to integrate the directory structure at "[RFD] CAT user space interface revisited" ? Thanks. -- 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/