Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753116AbbKYWB7 (ORCPT ); Wed, 25 Nov 2015 17:01:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33715 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752541AbbKYWBu (ORCPT ); Wed, 25 Nov 2015 17:01:50 -0500 Date: Tue, 24 Nov 2015 23:29:29 -0200 From: Marcelo Tosatti To: Chao Peng , f@amt.cnet Cc: Thomas Gleixner , LKML , Peter Zijlstra , x86@kernel.org, Luiz Capitulino , Vikas Shivappa , Tejun Heo , Yu Fenghua Subject: Re: [RFD] CAT user space interface revisited Message-ID: <20151125012927.GA29177@amt.cnet> References: <20151119000153.GA27997@amt.cnet> <20151124082754.GB17000@pengc-linux.bj.intel.com> <20151124212543.GA11303@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151124212543.GA11303@amt.cnet> 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: 2444 Lines: 63 On Tue, Nov 24, 2015 at 07:25:43PM -0200, Marcelo Tosatti wrote: > On Tue, Nov 24, 2015 at 04:27:54PM +0800, Chao Peng wrote: > > On Wed, Nov 18, 2015 at 10:01:54PM -0200, Marcelo Tosatti wrote: > > > > tglx > > > > > > Again: you don't need to look into the MSR table and relate it > > > to tasks if you store the data as: > > > > > > task group 1 = { > > > reservation-1 = {size = 80Kb, type = data, socketmask = 0xffff}, > > > reservation-2 = {size = 100Kb, type = code, socketmask = 0xffff} > > > } > > > > > > task group 2 = { > > > reservation-1 = {size = 80Kb, type = data, socketmask = 0xffff}, > > > reservation-3 = {size = 200Kb, type = code, socketmask = 0xffff} > > > } > > > > > > Task group 1 and task group 2 share reservation-1. > > > > Because there is only size but not CBM position info, I guess for > > different reservations they will not overlap each other, right? > > Reservation 1 is shared between task group 1 and task group 2 > so the CBMs overlap (by 80Kb, rounded). > > > Personally I like this way of exposing minimal information to userspace. > > I can think it working well except for one concern of losing flexibility: > > > > For instance, there is a box for which the full CBM is 0xfffff. After > > cache reservation creating/freeing for a while we then have reservations: > > > > reservation1: 0xf0000 > > reservation2: 0x00ff0 > > > > Now people want to request a reservation which size is 0xff, so how > > will kernel do at this time? It could return just error or do some > > moving/merging (e.g. for reservation2: 0x00ff0 => 0x0ff00) and then > > satisfy the request. But I don't know if the moving/merging will cause > > delay for tasks that is using it. > > Right, i was thinking of adding a "force" parameter. > > So, default behaviour of attach: do not merge. > "force" behaviour of attach: move reservations around and merge if > necessary. To make the decision userspace would need the know that a merge can be performed if particular reservations can be moved (that is, the moveable property is per-reservation, depending on whether its ok for the given app to cacheline fault or not). Anyway, thats for later. -- 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/