Received: by 10.223.185.116 with SMTP id b49csp6572117wrg; Wed, 28 Feb 2018 11:42:06 -0800 (PST) X-Google-Smtp-Source: AH8x224RikvqgOyVPJkVnrNvIRKryvQnANbHLkD9gSyCAIpHymjypnBsZBvB5odyp5LcS7WN8Xce X-Received: by 2002:a17:902:20e6:: with SMTP id v35-v6mr19010095plg.226.1519846926626; Wed, 28 Feb 2018 11:42:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519846926; cv=none; d=google.com; s=arc-20160816; b=VD3ehZSmoMJGSraHLwUTzfKa3xJL4Vn4+DkOoRVgMehf/GRp7mFhcFWAer1iZd5431 +bhQziqcbTZznxNq+X4uDthykrb0NsrumFP2oyALMJcPjQyg+UZMacQRJeEEm5bX9ESz U8pcc8K7z9hwF1zWpHMK+aLgEUzPC9S7j0gqE58A4+5f6Y/1HicUpE7i84FpHUjbQ1mL a1a/3RklmwK56nA8P9zeu41CNAZ1b04WbXttfq/p9eU1Ljp6xTpq0ZSP9yEcAwgwU2Ag 5ed5moFXh6IXlHQaoWCE5ndiq2jgoIoVx2dQyQGISI0M8mZnUWvxW+gYsDMuyQnU7ioM K8uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=6pRcwxPVKOgeB7JIXG61inO7TjI6QjlQt61EfbwD3eY=; b=qq+YbIDvf9nWu1xLltnbiI3QAP3fsYru/pYIlOD+Rpg0oEDMLtrMHQRFfJlWfVe+1e PZLlf7KQn6SDco0y2Kp4TaErUpWAg8eE0WNe4lOrBvH0wpQTrIkEFXyCHvC9B4nQk7t1 pIy0jZx+x4jgGbUDWw+I9Ocd0FFduuE9wA9V/AfDPE/OW/b9VDCnJbFlnhyzmmo4RNF2 vnidLd3u1ij1SptO5OzaHGd5qzCle45/Lor+6ukeQvdGVXCVJ01TRpovKgOH3gyWldmq 9bsBoHfGjpW5CvqaDm/FVVR3RJlE+OpajhGbhhFeH/Ptkii9oS+mnTmGV1Q1oM2c1Ac1 KG+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c19si1672273pfd.343.2018.02.28.11.41.51; Wed, 28 Feb 2018 11:42:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933738AbeB1TlR (ORCPT + 99 others); Wed, 28 Feb 2018 14:41:17 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:49440 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933385AbeB1TlQ (ORCPT ); Wed, 28 Feb 2018 14:41:16 -0500 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1er7XH-0004Mo-8r; Wed, 28 Feb 2018 20:37:07 +0100 Date: Wed, 28 Feb 2018 20:40:43 +0100 (CET) From: Thomas Gleixner To: Reinette Chatre cc: fenghua.yu@intel.com, tony.luck@intel.com, gavin.hindman@intel.com, vikas.shivappa@linux.intel.com, dave.hansen@intel.com, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core In-Reply-To: <7695220e-2503-d598-d9bd-cd0256028fce@intel.com> Message-ID: References: <73fb98d2-ce93-0443-b909-fde75908cc1e@intel.com> <69ed85f2-b9c5-30d1-8437-45f20be3e95e@intel.com> <7695220e-2503-d598-d9bd-cd0256028fce@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 28 Feb 2018, Reinette Chatre wrote: > On 2/28/2018 10:39 AM, Thomas Gleixner wrote: > > I came up with this under the assumptions: > > > > 1) One locked region per resource group > > 2) Drop closid after locking > > I am also now working under these assumptions ... > > > Then the restrict file makes a lot of sense because it would give a clear > > selection of the possible resource to lock. > > ... but I am still stuck on why this restrict file is needed at this > time. Surely it would be needed if later we add the more flexible > exclusive mode, but I do not understand how it helps the locked mode. You're right. Brainfart on my side. With that scheme it's really only useful for a flexible exclusive mode, which would be nice to have but is not a prerequisite for now. Thanks, tglx