Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752744AbbKXIdN (ORCPT ); Tue, 24 Nov 2015 03:33:13 -0500 Received: from mga03.intel.com ([134.134.136.65]:33712 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbbKXIdM (ORCPT ); Tue, 24 Nov 2015 03:33:12 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,338,1444719600"; d="scan'208";a="693229019" Date: Tue, 24 Nov 2015 16:27:54 +0800 From: Chao Peng To: Marcelo Tosatti 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: <20151124082754.GB17000@pengc-linux.bj.intel.com> Reply-To: Chao Peng References: <20151119000153.GA27997@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151119000153.GA27997@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: 1611 Lines: 43 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? 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. Thanks, Chao -- 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/