[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <5c140012cca1f7215a452dcb5074bd57fbe558fb.1510568528.git.reinette.chatre@intel.com>
Date: Mon, 13 Nov 2017 08:39:33 -0800
From: Reinette Chatre <reinette.chatre@...el.com>
To: tglx@...utronix.de, fenghua.yu@...el.com, tony.luck@...el.com
Cc: vikas.shivappa@...ux.intel.com, dave.hansen@...el.com,
mingo@...hat.com, hpa@...or.com, x86@...nel.org,
linux-kernel@...r.kernel.org,
Reinette Chatre <reinette.chatre@...el.com>
Subject: [RFC PATCH 10/20] x86/intel_rdt: Disable pseudo-locking if CDP enabled
Pseudo-locking can work when Code and Data Prioritization (CDP) is enabled,
but there are a few additional checks and actions involved. At this time
it is not clear if users would want to use pseudo-locking and CDP at the
same time so the support of this is delayed until we understand the
usage better.
Disable pseudo-locking if CDP is enabled. Add the details of things to
keep in mind for anybody considering enabling this support.
Signed-off-by: Reinette Chatre <reinette.chatre@...el.com>
---
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
index a0c144b5b09b..d2fe8ef7e74a 100644
--- a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
+++ b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
@@ -443,6 +443,34 @@ int rdt_pseudo_lock_fs_init(struct kernfs_node *root)
lockdep_assert_held(&rdtgroup_mutex);
/*
+ * Pseudo-locking not supported when CDP is enabled.
+ *
+ * Some things to consider if you would like to enable this support:
+ * - When CDP is enabled two separate resources are exposed, L3DATA
+ * and L3CODE, but they are actually on the same cache. The
+ * implication for pseudo-locking is that if a pseudo-locked
+ * region is created on a domain of one resource (eg. L3CODE),
+ * then a pseudo-locked region cannot be created on that same
+ * domain of the other resource (eg. L3DATA). This is because
+ * the creation of a pseudo-locked region involves a call to
+ * wbinvd that will affect all cache allocations on particular
+ * domain.
+ * - Considering the previous, it may be possible to only expose
+ * one of the CDP resources to pseudo-locking and hide the other.
+ * For example, we could consider to only expose L3DATA and since
+ * the L3 cache is unified it is still possible to place
+ * instructions there are execute it.
+ * - If only one region is exposed to pseudo-locking we should still
+ * keep in mind that availability of a portion of cache for
+ * pseudo-locking should take into account both resources. Similarly,
+ * if a pseudo-locked region is created in one resource, the portion
+ * of cache used by it should be made unavailable to all future
+ * allocations from both resources.
+ */
+ if (rdt_resources_all[RDT_RESOURCE_L3DATA].alloc_enabled)
+ return 0;
+
+ /*
* Not knowing the bits to disable prefetching is not a failure
* that should be propagated since we only return prefetching bits
* for those platforms pseudo-locking has been tested on. If
--
2.13.5
Powered by blists - more mailing lists