mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Reinette Chatre <reinette.chatre@intel.com>
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
Date: Sat, 18 Nov 2017 01:48:18 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711180133540.2186@nanos> (raw)
In-Reply-To: <cover.1510568528.git.reinette.chatre@intel.com>

Reinette,

On Mon, 13 Nov 2017, Reinette Chatre wrote:

thanks for that interesting work. Before I start looking into the details
in the next days let me ask a few general questions first.

> Cache Allocation Technology (CAT), part of Intel(R) Resource Director
> Technology (Intel(R) RDT), enables a user to specify the amount of cache
> space into which an application can fill. Cache pseudo-locking builds on
> the fact that a CPU can still read and write data pre-allocated outside
> its current allocated area on cache hit. With cache pseudo-locking data
> can be preloaded into a reserved portion of cache that no application can
> fill, and from that point on will only serve cache hits. The cache
> pseudo-locked memory is made accessible to user space where an application
> can map it into its virtual address space and thus have a region of
> memory with reduced average read latency.

Did you compare that against the good old cache coloring mechanism,
e.g. palloc ?

> 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?

> 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
what are those applications supposed to do once the feature breaks with
future generations of processors?

Thanks,

	tglx

  parent reply	other threads:[~2017-11-18  0:48 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 16:39 Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 01/20] x86/intel_rdt: Documentation for Cache Pseudo-Locking Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 02/20] x86/intel_rdt: Make useful functions available internally Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 03/20] x86/intel_rdt: Introduce hooks to create pseudo-locking files Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 04/20] x86/intel_rdt: Introduce test to determine if closid is in use Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 05/20] x86/intel_rdt: Print more accurate pseudo-locking availability Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 06/20] x86/intel_rdt: Create pseudo-locked regions Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 07/20] x86/intel_rdt: Connect pseudo-locking directory to operations Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 08/20] x86/intel_rdt: Introduce pseudo-locking resctrl files Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 09/20] x86/intel_rdt: Discover supported platforms via prefetch disable bits Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 10/20] x86/intel_rdt: Disable pseudo-locking if CDP enabled Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 11/20] x86/intel_rdt: Associate pseudo-locked regions with its domain Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 12/20] x86/intel_rdt: Support CBM checking from value and character buffer Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 13/20] x86/intel_rdt: Support schemata write - pseudo-locking core Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 14/20] x86/intel_rdt: Enable testing for pseudo-locked region Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 15/20] x86/intel_rdt: Prevent new allocations from pseudo-locked regions Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 16/20] x86/intel_rdt: Create debugfs files for pseudo-locking testing Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 17/20] x86/intel_rdt: Create character device exposing pseudo-locked region Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 18/20] x86/intel_rdt: More precise L2 hit/miss measurements Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 19/20] x86/intel_rdt: Support L3 cache performance event of Broadwell Reinette Chatre
2017-11-13 16:39 ` [RFC PATCH 20/20] x86/intel_rdt: Limit C-states dynamically when pseudo-locking active Reinette Chatre
2017-11-18  0:48 ` Thomas Gleixner [this message]
2017-11-18  6:42   ` [RFC PATCH 00/20] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling Reinette Chatre
2018-01-14 22:54     ` Thomas Gleixner
2018-01-15 16:23       ` Hindman, Gavin
2018-01-16 11:38         ` Thomas Gleixner
2018-01-17  0:53           ` Reinette Chatre
2018-02-12 19:07           ` Reinette Chatre
2018-02-13 10:27             ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1711180133540.2186@nanos \
    --to=tglx@linutronix.de \
    --cc=dave.hansen@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=tony.luck@intel.com \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®