All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Fenghua Yu <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	tglx@linutronix.de, fenghua.yu@intel.com,
	vikas.shivappa@linux.intel.com
Subject: [tip:x86/cache] x86,cgroup/intel_rdt : Add intel_rdt cgroup documentation
Date: Fri, 18 Dec 2015 13:36:51 -0800	[thread overview]
Message-ID: <tip-f5faa67fb17b931e2b0223dc8a4d29e64c9bfa9d@git.kernel.org> (raw)
In-Reply-To: <1450392376-6397-11-git-send-email-fenghua.yu@intel.com>

Commit-ID:  f5faa67fb17b931e2b0223dc8a4d29e64c9bfa9d
Gitweb:     http://git.kernel.org/tip/f5faa67fb17b931e2b0223dc8a4d29e64c9bfa9d
Author:     Fenghua Yu <fenghua.yu@intel.com>
AuthorDate: Thu, 17 Dec 2015 14:46:15 -0800
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Fri, 18 Dec 2015 13:17:57 -0800

x86,cgroup/intel_rdt : Add intel_rdt cgroup documentation

From: Vikas Shivappa <vikas.shivappa@linux.intel.com>

Add documentation on using the cache allocation cgroup interface with
examples.

Signed-off-by: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Link: http://lkml.kernel.org/r/1450392376-6397-11-git-send-email-fenghua.yu@intel.com
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
---
 Documentation/cgroups/rdt.txt | 133 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)

diff --git a/Documentation/cgroups/rdt.txt b/Documentation/cgroups/rdt.txt
new file mode 100644
index 0000000..9fa6c6a
--- /dev/null
+++ b/Documentation/cgroups/rdt.txt
@@ -0,0 +1,133 @@
+        RDT
+        ---
+
+Copyright (C) 2014 Intel Corporation
+Written by vikas.shivappa@linux.intel.com
+
+CONTENTS:
+=========
+
+1. Cache Allocation Technology
+  1.1 Why is Cache allocation needed?
+2. Usage Examples and Syntax
+
+1. Cache Allocation Technology
+===================================
+
+1.1 Why is Cache allocation needed
+----------------------------------
+
+In today's new processors the number of cores is continuously increasing
+especially in large scale usage models where VMs are used like
+webservers and datacenters. The number of cores increase the number of
+threads or workloads that can simultaneously be run. When
+multi-threaded-applications, VMs, workloads run concurrently they
+compete for shared resources including L3 cache.
+
+The architecture also allows dynamically changing these subsets during
+runtime to further optimize the performance of the higher priority
+application with minimal degradation to the low priority app.
+Additionally, resources can be rebalanced for system throughput benefit.
+This technique may be useful in managing large computer systems which
+large L3 cache.
+
+Cloud/Container use case:
+The key use case scenarios are in large server clusters in a typical
+cloud or container context. A central 'managing agent' would control
+resource allocations to a set of VMs or containers. In today's resource
+management, cgroups are widely used already and a significant amount of
+plumbing in user space is already done to perform tasks like
+allocating/configuring resources dynamically and statically. An
+important example is dockers using systemd and systemd in turn using
+cgroups in its core to manage resources. This makes cgroup interface an
+easily adaptable interface for cache allocation.
+
+Noisy neighbour use case:
+A more specific use case may be when a streaming app which is constantly
+copying data and accessing linear space larger than L3 cache
+and hence evicting a large amount of cache which could have
+otherwise been used by a high priority computing application. Using the
+cache allocation feature, the 'noisy neighbours' like the streaming
+application can be confined to use a smaller cache and the high priority
+application be awarded a larger amount of cache space. A managing agent
+can monitor the cache allocation using cache monitoring through libperf
+and be able to make resource adjustments either statically or
+dynamically.
+This interface hence helps in maintaining a resource policy to
+provide the quality of service requirements like number of requests
+handled, response time.
+
+More information can be found in the Intel SDM June 2015, Volume 3,
+section 17.16. More information on kernel implementation details can be
+found in Documentation/x86/intel_rdt.txt.
+
+2. Usage examples and syntax
+============================
+
+Following is an example on how a system administrator/root user can
+configure L3 cache allocation to threads.
+
+To enable the cache allocation during compile time set the
+CONFIG_INTEL_RDT=y.
+
+To check if Cache allocation was enabled on your system
+  $ dmesg | grep -i intel_rdt
+  intel_rdt: Intel Cache Allocation enabled
+
+  $ cat /proc/cpuinfo
+output would have 'rdt' (if rdt is enabled) and 'cat_l3' (if L3
+cache allocation is enabled).
+
+example1: Following would mount the cache allocation cgroup subsystem
+and create 2 directories.
+
+  $ cd /sys/fs/cgroup
+  $ mkdir rdt
+  $ mount -t cgroup -ointel_rdt intel_rdt /sys/fs/cgroup/rdt
+  $ cd rdt
+  $ mkdir group1
+  $ mkdir group2
+
+Following are some of the Files in the directory
+
+  $ ls
+  intel_rdt.l3_cbm
+  tasks
+
+Say if the cache is 4MB (looked up from /proc/cpuinfo) and max cbm is 16
+bits (indicated by the root nodes cbm). This assigns 1MB of cache to
+group1 and group2 which is exclusive between them.
+
+  $ cd group1
+  $ /bin/echo 0xf > intel_rdt.l3_cbm
+
+  $ cd group2
+  $ /bin/echo 0xf0 > intel_rdt.l3_cbm
+
+Assign tasks to the group2
+
+  $ /bin/echo PID1 > tasks
+  $ /bin/echo PID2 > tasks
+
+Now threads PID1 and PID2 get to fill the 1MB of cache that was
+allocated to group2. Similarly assign tasks to group1.
+
+example2: Below commands allocate '1MB L3 cache on socket1 to group1'
+and '2MB of L3 cache on socket2 to group2'.
+This mounts both cpuset and intel_rdt and hence the ls would list the
+files in both the subsystems.
+  $ mount -t cgroup -ocpuset,intel_rdt cpuset,intel_rdt rdt/
+
+Assign the cache
+  $ /bin/echo 0xf > /sys/fs/cgroup/rdt/group1/intel_rdt.l3_cbm
+  $ /bin/echo 0xff > /sys/fs/cgroup/rdt/group2/intel_rdt.l3_cbm
+
+Assign tasks for group1 and group2
+  $ /bin/echo PID1 > /sys/fs/cgroup/rdt/group1/tasks
+  $ /bin/echo PID2 > /sys/fs/cgroup/rdt/group1/tasks
+  $ /bin/echo PID3 > /sys/fs/cgroup/rdt/group2/tasks
+  $ /bin/echo PID4 > /sys/fs/cgroup/rdt/group2/tasks
+
+Tie the group1 to socket1 and group2 to socket2
+  $ /bin/echo <cpumask for socket1> > /sys/fs/cgroup/rdt/group1/cpuset.cpus
+  $ /bin/echo <cpumask for socket2> > /sys/fs/cgroup/rdt/group2/cpuset.cpus

  reply	other threads:[~2015-12-18 21:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-17 22:46 [PATCH V16 00/11] x86: Intel Cache Allocation Technology Support Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 01/11] x86/intel_cqm: Modify hot cpu notification handling Fenghua Yu
2015-12-18 21:33   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 02/11] x86/intel_rapl: " Fenghua Yu
2015-12-18 21:34   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 03/11] x86/intel_rdt: Cache Allocation documentation Fenghua Yu
2015-12-18 21:34   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 04/11] x86/intel_rdt: Add support for Cache Allocation detection Fenghua Yu
2015-12-18 21:34   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 05/11] x86/intel_rdt: Add Class of service management Fenghua Yu
2015-12-18 21:35   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 06/11] x86/intel_rdt: Add L3 cache capacity bitmask management Fenghua Yu
2015-12-18 21:35   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 07/11] x86/intel_rdt: Implement scheduling support for Intel RDT Fenghua Yu
2015-12-18 21:35   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 08/11] x86/intel_rdt: Hot cpu support for Cache Allocation Fenghua Yu
2015-12-18 21:36   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 09/11] x86/intel_rdt: Intel haswell Cache Allocation enumeration Fenghua Yu
2015-12-18 21:36   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-17 22:46 ` [PATCH V16 10/11] x86,cgroup/intel_rdt : Add intel_rdt cgroup documentation Fenghua Yu
2015-12-18 21:36   ` tip-bot for Fenghua Yu [this message]
2015-12-17 22:46 ` [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation Fenghua Yu
2015-12-18 21:37   ` [tip:x86/cache] " tip-bot for Fenghua Yu
2015-12-19 10:42   ` [PATCH V16 11/11] " Thomas Gleixner
2015-12-20  0:57     ` Marcelo Tosatti
2015-12-21 13:44       ` Thomas Gleixner
2015-12-21 15:48       ` Luiz Capitulino
2015-12-21 17:05         ` Marcelo Tosatti
2016-01-02 22:53           ` Richard Weinberger
2016-01-04 21:44             ` Yu, Fenghua
2016-01-04 21:47               ` Richard Weinberger
2015-12-18 17:45 ` [PATCH V16 00/11] x86: Intel Cache Allocation Technology Support Christoph Lameter
2015-12-18 20:49   ` Marcelo Tosatti
2015-12-21 12:53     ` Christoph Lameter
2015-12-21 15:55 ` Luiz Capitulino
2015-12-23 15:50 ` Tejun Heo

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=tip-f5faa67fb17b931e2b0223dc8a4d29e64c9bfa9d@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vikas.shivappa@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.