linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: tglx@linutronix.de, fenghua.yu@intel.com, tony.luck@intel.com
Cc: jithu.joseph@intel.com, gavin.hindman@intel.com,
	dave.hansen@intel.com, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Reinette Chatre <reinette.chatre@intel.com>
Subject: [PATCH V2 0/3] x86/intel_rdt: Fix exclusive mode with CDP resources
Date: Wed,  3 Oct 2018 15:17:00 -0700	[thread overview]
Message-ID: <cover.1538603665.git.reinette.chatre@intel.com> (raw)

Changes in V2:
- Have the new rdt_cdp_peer_get() return EINVAL instead of ENOENT when
  only one of the CDP peers have a rdt_domain associated with it.
- Rename _rdtgroup_cbm_overlaps() to __rdtgroup_cbm_overlaps() to stand out
  more.
- Fix kernel-doc to match function parameter name.
- Rename rdtgroup_cbm_overlaps()'s _cbm function parameter to cbm.
- Simplify the code in rdtgroup_cbm_overlaps() to make the flow more
  obvious.

Nothing (apart from diffstat) changed below since original submission.

Dear Maintainers,

CDP resources do not currently behave as expected when there are resource
groups with mode 'exclusive'.

In the example below it was possible to create two resource groups,
p1 and p2, that are both in exclusive mode but their usage of the
underlying L2 cache actually overlaps.

root@glk:/sys/fs/resctrl# ls
cpus  cpus_list  info  mode  p1  p2  schemata  size  tasks
root@glk:/sys/fs/resctrl# cat schemata
L2DATA:0=fff0
L2CODE:0=fff0
root@glk:/sys/fs/resctrl# cat mode
shareable

root@glk:/sys/fs/resctrl# cat p1/schemata
L2DATA:0=0003
L2CODE:0=000c
root@glk:/sys/fs/resctrl# cat p1/mode
exclusive

root@glk:/sys/fs/resctrl# cat p2/schemata
L2DATA:0=000c
L2CODE:0=0003
root@glk:/sys/fs/resctrl# cat p2/mode
exclusive

root@glk:/sys/fs/resctrl# cat info/L2CODE/bit_usage
0=SSSSSSSSSSSSEEEE
root@glk:/sys/fs/resctrl# cat info/L2DATA/bit_usage
0=SSSSSSSSSSSSEEEE
root@glk:/sys/fs/resctrl#

In the above example, the CBM of L2DATA in p1 overlaps with the CBM of
L2CODE in p2 while they are both in exclusive mode. While it may reflect no
overlap among the L2DATA resources specifically it does actually imply
overlap of use of the underlying hardware that is not the intention of
'exclusive' mode. This happens because the current implementation treats
L2CODE and L2DATA as totally independent, when it is actually referring to
the same underlying hardware.

This series fixes the potential for overlap of hardware resource use when
resource groups are in 'exclusive' mode by ensuring that if there is a CDP
peer on the same hardware then any overlap test would consider it also.

Allocations of data and code resources within the same exclusive resource
group are allowed to overlap.

Your feedback will be greatly appreciated.

Reinette

Reinette Chatre (3):
  x86/intel_rdt: Introduce utility to obtain CDP peer
  x86/intel_rdt: CBM overlap should also check for overlap with CDP peer
  x86/intel_rdt: Fix initial allocation to consider CDP

 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 133 ++++++++++++++++++++++-
 1 file changed, 127 insertions(+), 6 deletions(-)

-- 
2.17.0


             reply	other threads:[~2018-10-03 22:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 22:17 Reinette Chatre [this message]
2018-10-03 22:17 ` [PATCH V2 1/3] x86/intel_rdt: Introduce utility to obtain CDP peer Reinette Chatre
2018-10-06 18:51   ` [tip:x86/cache] " tip-bot for Reinette Chatre
2018-10-09  7:01   ` tip-bot for Reinette Chatre
2018-10-03 22:17 ` [PATCH V2 2/3] x86/intel_rdt: CBM overlap should also check for overlap with " Reinette Chatre
2018-10-06 18:52   ` [tip:x86/cache] " tip-bot for Reinette Chatre
2018-10-09  7:02   ` tip-bot for Reinette Chatre
2018-10-03 22:17 ` [PATCH V2 3/3] x86/intel_rdt: Fix initial allocation to consider CDP Reinette Chatre
2018-10-06 18:53   ` [tip:x86/cache] " tip-bot for Reinette Chatre
2018-10-09  7:03   ` tip-bot for Reinette Chatre

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=cover.1538603665.git.reinette.chatre@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=gavin.hindman@intel.com \
    --cc=hpa@zytor.com \
    --cc=jithu.joseph@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@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;
as well as URLs for NNTP newsgroup(s).