From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Tejun Heo <tj@kernel•org>, Thomas Gleixner <tglx@linutronix•de>,
Ingo Molnar <mingo@elte•hu>, "H. Peter Anvin" <hpa@zytor•com>,
Peter Zijlstra <peterz@infradead•org>
Cc: linux-next@vger•kernel.org, linux-kernel@vger•kernel.org,
Fenghua Yu <fenghua.yu@intel•com>,
Johannes Weiner <hannes@cmpxchg•org>
Subject: linux-next: manual merge of the cgroup tree with the tip tree
Date: Mon, 21 Dec 2015 15:41:19 +1100 [thread overview]
Message-ID: <20151221154119.66094285@canb.auug.org.au> (raw)
Hi Tejun,
Today's linux-next merge of the cgroup tree got a conflict in:
init/Kconfig
between commits:
257372262056 ("x86/intel_rdt: Add support for Cache Allocation detection")
5ad9144cdb9a ("x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation")
from the tip tree and commit:
6bf024e69333 ("cgroup: put controller Kconfig options in meaningful order")
from the cgroup tree.
I fixed it up (see below - I wasn't sure where to put the new INTEL_RDT
config option) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
diff --cc init/Kconfig
index 4139128e3cab,f8754f502c36..000000000000
--- a/init/Kconfig
+++ b/init/Kconfig
@@@ -935,77 -940,6 +935,18 @@@ menuconfig CGROUP
if CGROUPS
+config INTEL_RDT
+ bool "Intel Resource Director Technology support"
+ depends on X86_64 && CPU_SUP_INTEL
+ help
+ This option provides support for Cache allocation which is a
+ sub-feature of Intel Resource Director Technology(RDT).
+ Current implementation supports L3 cache allocation.
+ Using this feature a user can specify the amount of L3 cache space
+ into which an application can fill.
+
+ Say N if unsure.
+
- config CGROUP_DEBUG
- bool "Example debug cgroup subsystem"
- default n
- help
- This option enables a simple cgroup subsystem that
- exports useful debugging information about the cgroups
- framework.
-
- Say N if unsure.
-
- config CGROUP_FREEZER
- bool "Freezer cgroup subsystem"
- help
- Provides a way to freeze and unfreeze all tasks in a
- cgroup.
-
- config CGROUP_PIDS
- bool "PIDs cgroup subsystem"
- help
- Provides enforcement of process number limits in the scope of a
- cgroup. Any attempt to fork more processes than is allowed in the
- cgroup will fail. PIDs are fundamentally a global resource because it
- is fairly trivial to reach PID exhaustion before you reach even a
- conservative kmemcg limit. As a result, it is possible to grind a
- system to halt without being limited by other cgroup policies. The
- PIDs cgroup subsystem is designed to stop this from happening.
-
- It should be noted that organisational operations (such as attaching
- to a cgroup hierarchy will *not* be blocked by the PIDs subsystem),
- since the PIDs limit only affects a process's ability to fork, not to
- attach to a cgroup.
-
- config CGROUP_DEVICE
- bool "Device controller for cgroups"
- help
- Provides a cgroup implementing whitelists for devices which
- a process in the cgroup can mknod or open.
-
- config CPUSETS
- bool "Cpuset support"
- help
- This option will let you create and manage CPUSETs which
- allow dynamically partitioning a system into sets of CPUs and
- Memory Nodes and assigning tasks to run only within those sets.
- This is primarily useful on large SMP or NUMA systems.
-
- Say N if unsure.
-
- config PROC_PID_CPUSET
- bool "Include legacy /proc/<pid>/cpuset file"
- depends on CPUSETS
- default y
-
- config CGROUP_CPUACCT
- bool "Simple CPU accounting cgroup subsystem"
- help
- Provides a simple Resource Controller for monitoring the
- total CPU consumed by the tasks in a cgroup.
-
config PAGE_COUNTER
bool
next reply other threads:[~2015-12-21 4:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 4:41 Stephen Rothwell [this message]
2015-12-21 4:48 ` linux-next: manual merge of the cgroup tree with the tip tree Tejun Heo
2016-01-11 15:15 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2025-11-25 5:15 Stephen Rothwell
2022-09-12 5:59 Stephen Rothwell
2022-10-10 21:00 ` Stephen Rothwell
2015-12-21 4:41 Stephen Rothwell
2015-10-16 5:40 Stephen Rothwell
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=20151221154119.66094285@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=fenghua.yu@intel$(echo .)com \
--cc=hannes@cmpxchg$(echo .)org \
--cc=hpa@zytor$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=peterz@infradead$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
--cc=tj@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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