From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752757AbeANWyf (ORCPT + 1 other); Sun, 14 Jan 2018 17:54:35 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:38672 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751302AbeANWye (ORCPT ); Sun, 14 Jan 2018 17:54:34 -0500 Date: Sun, 14 Jan 2018 23:54:14 +0100 (CET) From: Thomas Gleixner To: Reinette Chatre cc: fenghua.yu@intel.com, tony.luck@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 00/20] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling In-Reply-To: <93415e33-6adf-047f-9a46-0862c3cd33b6@intel.com> Message-ID: References: <93415e33-6adf-047f-9a46-0862c3cd33b6@intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, 17 Nov 2017, Reinette Chatre wrote: Sorry for the delay. You know why :) > On 11/17/2017 4:48 PM, Thomas Gleixner wrote: > > On Mon, 13 Nov 2017, Reinette Chatre wrote: > > Did you compare that against the good old cache coloring mechanism, > > e.g. palloc ? > > I understand where your question originates. I have not compared against > PALLOC for two reasons: > > 1) PALLOC is not upstream and while inquiring about the status of this > work (please see https://github.com/heechul/palloc/issues/4 for details) > we learned that one reason for this is that recent Intel processors are > not well supported. So if I understand Heechul correctly then recent CPUs cannot be supported easily due to changes in the memory controllers and the cache. I assume the latter is related to CAT. > 2) The most recent kernel supported by PALLOC is v4.4 and also mentioned > in the above link there is currently no plan to upstream this work for a > less divergent comparison of PALLOC and the more recent RDT/CAT enabling > on which Cache Pseudo-Locking is built. Well, that's not a really good excuse for not trying. You at Intel should be able to get to the parameters easy enough :) > >> The cache pseudo-locking approach relies on generation-specific behavior > >> of processors. It may provide benefits on certain processor generations, > >> but is not guaranteed to be supported in the future. > > > > Hmm, are you saying that the CAT mechanism might change radically in the > > future so that access to cached data in an allocated area which does not > > belong to the current executing context wont work anymore? > > Most devices that publicly support CAT in the Linux mainline can take > advantage of Cache Pseudo-Locking. However, Cache Pseudo-Locking is a > model-specific feature so there may be some variation in if, or to what > extent, current and future devices can support Cache Pseudo-Locking. CAT > remains architectural. Sure, but that does NOT answer my question at all. > >> It is not a guarantee that data will remain in the cache. It is not a > >> guarantee that data will remain in certain levels or certain regions of > >> the cache. Rather, cache pseudo-locking increases the probability that > >> data will remain in a certain level of the cache via carefully > >> configuring the CAT feature and carefully controlling application > >> behavior. > > > > Which kind of applications are you targeting with that? > > > > Are there real world use cases which actually can benefit from this and > > To ensure I answer your question I will consider two views. First, the >"carefully controlling application behavior" referred to above refers to > applications/OS/VMs running after the pseudo-locked regions have been set > up. These applications should take care to not do anything, for example > call wbinvd, that would affect the Cache Pseudo-Locked regions. Second, > what you are also asking about is the applications using these Cache > Pseudo-Locked regions. We do see a clear performance benefit to > applications using these pseudo-locked regions. Latency sensitive > applications could relocate their code as well as data to pseudo-locked > regions for improved performance. This is again a marketing pitch and not answering my question about real world use cases. > > what are those applications supposed to do once the feature breaks with > > future generations of processors? > > This feature is model specific with a few platforms supporting it at this > time. Only platforms known to support Cache Pseudo-Locking will expose > its resctrl interface. And you deliberately avoided to answer my question again. Thanks, tglx