Skip to contentSkip to conversation

Introduction

PATCH In review Paul Turner 7 participants 71 messages Feb 16, 2011 – Mar 9, 2011 1 message not in the archive

Subsystems (3)
lore
Share & tools
lore
#12 lore raw

PATCH v4 3/7 sched: throttle cfs_rq entities which exceed their local quota

In reply to Paul Turner

In account_cfs_rq_quota() (via update_curr()) we track consumption versus a cfs_rq's local quota and whether there is global quota available to continue enabling it in the event we run out.

This patch adds the required support for the latter case, throttling entities until quota is available to run. Throttling dequeues the entity in question and sends a reschedule to the owning cpu so that it can be evicted.

The following restrictions apply to a throttled cfs_rq:
- It is dequeued from sched_entity hierarchy and restricted from being re-enqueued. This means that new/waking children of this entity will be queued up to it, but not past it.
- It does not contribute to weight calculations in tg_shares_up
- In the case that the cfs_rq of the cpu we are trying to pull from is throttled it is is ignored by the loadbalancer in __load_balance_fair() and move_one_task_fair().

---
 kernel/sched.c      |    3 +
 kernel/sched_fair.c |  121 +++++++++++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 114 insertions(+), 10 deletions(-)
kernel/sched.c +3 -0
Index: tip/kernel/sched.c
===================================================================
@@ -388,6 +388,7 @@ struct cfs_rq {
 #endif
 #ifdef CONFIG_CFS_BANDWIDTH
 	u64 quota_assigned, quota_used;
+	int throttled;
 #endif
 #endif
 };
@@ -1656,6 +1657,8 @@ static void update_h_load(long cpu)
 
 static void double_rq_lock(struct rq *rq1, struct rq *rq2);
 
+static inline int cfs_rq_throttled(struct cfs_rq *cfs_rq);
+
 /*
  * fair double_lock_balance: Safely acquires both rq->locks in a fair
  * way at the expense of forcing extra atomic operations in all
kernel/sched_fair.c +111 -10

206 lines not on this page · raw message

#7 lore raw

PATCH v4 2/7 sched: accumulate per-cfs_rq cpu usage

In reply to Paul Turner

Introduce account_cfs_rq_quota() to account bandwidth usage on the cfs_rq level versus task_groups for which bandwidth has been assigned. This is tracked by whether the local cfs_rq->quota_assigned is finite or infinite (RUNTIME_INF).

For cfs_rq's that belong to a bandwidth constrained task_group we introduce tg_request_cfs_quota() which attempts to allocate quota from the global pool for use locally. Updates involving the global pool are currently protected under cfs_bandwidth->lock, local pools are protected by rq->lock.

This patch only attempts to assign and track quota, no action is taken in the case that cfs_rq->quota_used exceeds cfs_rq->quota_assigned.

---
 include/linux/sched.h |    4 +++
 kernel/sched_fair.c   |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++
 kernel/sysctl.c       |   10 ++++++++
 3 files changed, 76 insertions(+)
kernel/sched_fair.c +62 -0
Index: tip/kernel/sched_fair.c
===================================================================
@@ -95,6 +95,13 @@ unsigned int __read_mostly sysctl_sched_
  * default: 0.5s, units: nanoseconds
  */
 static u64 sched_cfs_bandwidth_period = 500000000ULL;
+
+/*
+ * default slice of quota to allocate from global tg to local cfs_rq pool on
+ * each refresh
+ * default: 10ms, units: microseconds
+ */
+unsigned int sysctl_sched_cfs_bandwidth_slice = 10000UL;
 #endif
 
 static const struct sched_class fair_sched_class;
@@ -313,6 +320,21 @@ find_matching_se(struct sched_entity **s
 
 #endif	/* CONFIG_FAIR_GROUP_SCHED */
 
+#ifdef CONFIG_CFS_BANDWIDTH
+static inline u64 sched_cfs_bandwidth_slice(void)
+{
+	return (u64)sysctl_sched_cfs_bandwidth_slice * NSEC_PER_USEC;
+}
+
+static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg)
+{
+	return &tg->cfs_bandwidth;
+}
+
+static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
+		unsigned long delta_exec);
+#endif
+
 
 /**************************************************************
  * Scheduling class tree data structure manipulation methods:
@@ -609,6 +631,9 @@ static void update_curr(struct cfs_rq *c
 		cpuacct_charge(curtask, delta_exec);
 		account_group_exec_runtime(curtask, delta_exec);
 	}
+#ifdef CONFIG_CFS_BANDWIDTH
+	account_cfs_rq_quota(cfs_rq, delta_exec);
+#endif
 }
 
 static inline void
@@ -1382,6 +1407,43 @@ static void dequeue_task_fair(struct rq 
 }
 
 #ifdef CONFIG_CFS_BANDWIDTH
+static u64 tg_request_cfs_quota(struct task_group *tg)
+{
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);
+	u64 delta = 0;
+
+	if (cfs_b->runtime > 0 || cfs_b->quota == RUNTIME_INF) {
+		raw_spin_lock(&cfs_b->lock);
+		/*
+		 * it's possible a bandwidth update has changed the global
+		 * pool.
+		 */
+		if (cfs_b->quota == RUNTIME_INF)
+			delta = sched_cfs_bandwidth_slice();
+		else {
+			delta = min(cfs_b->runtime,
+					sched_cfs_bandwidth_slice());
+			cfs_b->runtime -= delta;
+		}
+		raw_spin_unlock(&cfs_b->lock);
+	}
+	return delta;
+}
+
+static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
+		unsigned long delta_exec)
+{
+	if (cfs_rq->quota_assigned == RUNTIME_INF)
+		return;
+
+	cfs_rq->quota_used += delta_exec;
+
+	if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+		return;
+
+	cfs_rq->quota_assigned += tg_request_cfs_quota(cfs_rq->tg);
+}
+
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
 {
 	return 1;
kernel/sysctl.c +10 -0
Index: tip/kernel/sysctl.c
===================================================================
@@ -361,6 +361,16 @@ static struct ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= sched_rt_handler,
 	},
+#ifdef CONFIG_CFS_BANDWIDTH
+	{
+		.procname	= "sched_cfs_bandwidth_slice_us",
+		.data		= &sysctl_sched_cfs_bandwidth_slice,
+		.maxlen		= sizeof(unsigned int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= &one,
+	},
+#endif
 #ifdef CONFIG_SCHED_AUTOGROUP
 	{
 		.procname	= "sched_autogroup_enabled",
include/linux/sched.h +4 -0
Index: tip/include/linux/sched.h
===================================================================
@@ -1943,6 +1943,10 @@ int sched_rt_handler(struct ctl_table *t
 		void __user *buffer, size_t *lenp,
 		loff_t *ppos);
 
+#ifdef CONFIG_CFS_BANDWIDTH
+extern unsigned int sysctl_sched_cfs_bandwidth_slice;
+#endif
+
 #ifdef CONFIG_SCHED_AUTOGROUP
 extern unsigned int sysctl_sched_autogroup_enabled;
 
#40 lore raw

PATCH v4 5/7 sched: add exports tracking cfs bandwidth control statistics

In reply to Paul Turner

From: Nikhil Rao <[email protected]>

This change introduces statistics exports for the cpu sub-system, these are added through the use of a stat file similar to that exported by other subsystems.

The following exports are included:

nr_periods: number of periods in which execution occurred
nr_throttled: the number of periods above in which execution was throttle
throttled_time: cumulative wall-time that any cpus have been throttled for
this group

---
 kernel/sched.c      |   26 ++++++++++++++++++++++++++
 kernel/sched_fair.c |   16 +++++++++++++++-
 2 files changed, 41 insertions(+), 1 deletion(-)
kernel/sched.c +26 -0
Index: tip/kernel/sched.c
===================================================================
@@ -254,6 +254,11 @@ struct cfs_bandwidth {
 	ktime_t			period;
 	u64			runtime, quota;
 	struct hrtimer		period_timer;
+
+	/* throttle statistics */
+	u64			nr_periods;
+	u64			nr_throttled;
+	u64			throttled_time;
 };
 #endif
 
@@ -389,6 +394,7 @@ struct cfs_rq {
 #ifdef CONFIG_CFS_BANDWIDTH
 	u64 quota_assigned, quota_used;
 	int throttled;
+	u64 throttled_timestamp;
 #endif
 #endif
 };
@@ -426,6 +432,10 @@ void init_cfs_bandwidth(struct cfs_bandw
 
 	hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	cfs_b->period_timer.function = sched_cfs_period_timer;
+
+	cfs_b->nr_periods = 0;
+	cfs_b->nr_throttled = 0;
+	cfs_b->throttled_time = 0;
 }
 
 static
@@ -9332,6 +9342,18 @@ static int cpu_cfs_period_write_u64(stru
 	return tg_set_cfs_period(cgroup_tg(cgrp), cfs_period_us);
 }
 
+static int cpu_stats_show(struct cgroup *cgrp, struct cftype *cft,
+		struct cgroup_map_cb *cb)
+{
+	struct task_group *tg = cgroup_tg(cgrp);
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);
+
+	cb->fill(cb, "nr_periods", cfs_b->nr_periods);
+	cb->fill(cb, "nr_throttled", cfs_b->nr_throttled);
+	cb->fill(cb, "throttled_time", cfs_b->throttled_time);
+
+	return 0;
+}
 #endif /* CONFIG_CFS_BANDWIDTH */
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
@@ -9378,6 +9400,10 @@ static struct cftype cpu_files[] = {
 		.read_u64 = cpu_cfs_period_read_u64,
 		.write_u64 = cpu_cfs_period_write_u64,
 	},
+	{
+		.name = "stat",
+		.read_map = cpu_stats_show,
+	},
 #endif
 #ifdef CONFIG_RT_GROUP_SCHED
 	{
kernel/sched_fair.c +15 -1
Index: tip/kernel/sched_fair.c
===================================================================
@@ -1519,17 +1519,25 @@ static void throttle_cfs_rq(struct cfs_r
 
 out_throttled:
 	cfs_rq->throttled = 1;
+	cfs_rq->throttled_timestamp = rq_of(cfs_rq)->clock;
 	update_cfs_rq_load_contribution(cfs_rq, 1);
 }
 
 static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
 {
 	struct rq *rq = rq_of(cfs_rq);
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
 	struct sched_entity *se;
 
 	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
 
 	update_rq_clock(rq);
+	/* update stats */
+	raw_spin_lock(&cfs_b->lock);
+	cfs_b->throttled_time += (rq->clock - cfs_rq->throttled_timestamp);
+	raw_spin_unlock(&cfs_b->lock);
+	cfs_rq->throttled_timestamp = 0;
+
 	/* (Try to) avoid maintaining share statistics for idle time */
 	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;
 
@@ -1571,7 +1579,7 @@ static void account_cfs_rq_quota(struct 
 
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
 {
-	int i, idle = 1;
+	int i, idle = 1, num_throttled = 0;
 	u64 delta;
 	const struct cpumask *span;
 
@@ -1593,6 +1601,7 @@ static int do_sched_cfs_period_timer(str
 
 		if (!cfs_rq_throttled(cfs_rq))
 			continue;
+		num_throttled++;
 
 		delta = tg_request_cfs_quota(cfs_rq->tg);
 
@@ -1608,6 +1617,11 @@ static int do_sched_cfs_period_timer(str
 		}
 	}
 
+	/* update throttled stats */
+	cfs_b->nr_periods++;
+	if (num_throttled)
+		cfs_b->nr_throttled++;
+
 	return idle;
 }
 
#32 lore raw

PATCH v4 4/7 sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

In reply to Paul Turner

At the start of a new period there are several actions we must take:
- Refresh global bandwidth pool
- Unthrottle entities who ran out of quota as refreshed bandwidth permits

Unthrottled entities have the cfs_rq->throttled flag set and are re-enqueued into the cfs entity hierarchy.

sched_rt_period_mask() is refactored slightly into sched_bw_period_mask() since it is now shared by both cfs and rt bandwidth period timers.

The !CONFIG_RT_GROUP_SCHED && CONFIG_SMP case has been collapsed to use rd->span instead of cpu_online_mask since I think that was incorrect before (don't want to hit cpu's outside of your root_domain for RT bandwidth).

---
 kernel/sched.c      |   16 +++++++++++
 kernel/sched_fair.c |   74 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 kernel/sched_rt.c   |   19 -------------
 3 files changed, 90 insertions(+), 19 deletions(-)
kernel/sched.c +16 -0
Index: tip/kernel/sched.c
===================================================================
@@ -1561,6 +1561,8 @@ static int tg_nop(struct task_group *tg,
 }
 #endif
 
+static inline const struct cpumask *sched_bw_period_mask(void);
+
 #ifdef CONFIG_SMP
 /* Used instead of source_load when we know the type == 0 */
 static unsigned long weighted_cpuload(const int cpu)
@@ -8503,6 +8505,18 @@ void set_curr_task(int cpu, struct task_
 
 #endif
 
+#ifdef CONFIG_SMP
+static inline const struct cpumask *sched_bw_period_mask(void)
+{
+	return cpu_rq(smp_processor_id())->rd->span;
+}
+#else
+static inline const struct cpumask *sched_bw_period_mask(void)
+{
+	return cpu_online_mask;
+}
+#endif
+
 #ifdef CONFIG_FAIR_GROUP_SCHED
 static void free_fair_sched_group(struct task_group *tg)
 {
@@ -9240,6 +9254,8 @@ static int tg_set_cfs_bandwidth(struct t
 
 		raw_spin_lock_irq(&rq->lock);
 		init_cfs_rq_quota(cfs_rq);
+		if (cfs_rq_throttled(cfs_rq))
+			unthrottle_cfs_rq(cfs_rq);
 		raw_spin_unlock_irq(&rq->lock);
 	}
 	mutex_unlock(&mutex);
kernel/sched_fair.c +73 -1

93 lines not on this page · raw message

kernel/sched_rt.c +1 -18
Index: tip/kernel/sched_rt.c
===================================================================
@@ -252,18 +252,6 @@ static int rt_se_boosted(struct sched_rt
 	return p->prio != p->normal_prio;
 }
 
-#ifdef CONFIG_SMP
-static inline const struct cpumask *sched_rt_period_mask(void)
-{
-	return cpu_rq(smp_processor_id())->rd->span;
-}
-#else
-static inline const struct cpumask *sched_rt_period_mask(void)
-{
-	return cpu_online_mask;
-}
-#endif
-
 static inline
 struct rt_rq *sched_rt_period_rt_rq(struct rt_bandwidth *rt_b, int cpu)
 {
@@ -321,11 +309,6 @@ static inline int rt_rq_throttled(struct
 	return rt_rq->rt_throttled;
 }
 
-static inline const struct cpumask *sched_rt_period_mask(void)
-{
-	return cpu_online_mask;
-}
-
 static inline
 struct rt_rq *sched_rt_period_rt_rq(struct rt_bandwidth *rt_b, int cpu)
 {
@@ -543,7 +526,7 @@ static int do_sched_rt_period_timer(stru
 	if (!rt_bandwidth_enabled() || rt_b->rt_runtime == RUNTIME_INF)
 		return 1;
 
-	span = sched_rt_period_mask();
+	span = sched_bw_period_mask();
 	for_each_cpu(i, span) {
 		int enqueue = 0;
 		struct rt_rq *rt_rq = sched_rt_period_rt_rq(rt_b, i);
#0 lore raw

v4 cover Introduction

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Changes since v3:
- Rebased to current tip, update to work with new group scheduling accounting
- (Bug fix) Fixed Race with unthrottling (due to changing global limit) fixed
- (Bug fix) Fixed buddy interactions -- in particular, prevent buddy nominations from re-picking throttled entities

The skeleton of our approach is as follows:
- We maintain a global pool (per-tg) pool of unassigned quota. Within it we track the bandwidth period, quota per period, and runtime remaining in the current period. As bandwidth is used within a period it is decremented from runtime. Runtime is currently synchronized using a spinlock, in the current implementation there's no reason this couldn't be done using atomic ops instead however the spinlock allows for a little more flexibility in experimentation with other schemes.
- When a cfs_rq participating in a bandwidth constrained task_group executes it acquires time in sysctl_sched_cfs_bandwidth_slice (default currently 10ms) size chunks from the global pool, this synchronizes under rq->lock and is part of the update_curr path.
- Throttled entities are dequeued, we protect against their re-introduction to the scheduling hierarchy via checking for a, per cfs_rq, throttled bit.

Interface:
----------
Three new cgroupfs files are exported by the cpu subsystem:
cpu.cfs_period_us : period over which bandwidth is to be regulated cpu.cfs_quota_us : bandwidth available for consumption per period
cpu.stat : statistics (such as number of throttled periods and
total throttled time)
One important interface change that this introduces (versus the rate limits proposal) is that the defined bandwidth becomes an absolute quantifier.

Previous postings:
-----------------
v3:
https://lkml.org/lkml/2010/10/12/44
v2:
http://lkml.org/lkml/2010/4/28/88
Original posting:
http://lkml.org/lkml/2010/2/12/393

Prior approaches:
http://lkml.org/lkml/2010/1/5/44 ("CFS Hard limits v5")

Thanks,

- Paul

#58 lore raw

PATCH v4 7/7 sched: add documentation for bandwidth control

From: Bharata B Rao <[email protected]>

Basic description of usage and effect for CFS Bandwidth Control.

---
 Documentation/scheduler/sched-bwc.txt |   98
 ++++++++++++++++++++++++++++++++++
  1 file changed, 98 insertions(+)
Documentation/scheduler/sched-bwc.txt new file +98 -0
@@ -0,0 +1,98 @@
+CFS Bandwidth Control (aka CPU hard limits)
+===========================================
+
+[ This document talks about CPU bandwidth control of CFS groups only.
+  The bandwidth control of RT groups is explained in
+  Documentation/scheduler/sched-rt-group.txt ]
+
+CFS bandwidth control is a group scheduler extension that can be used to
+control the maximum CPU bandwidth obtained by a CPU cgroup.
+
+Bandwidth allowed for a group is specified using quota and period. Within
+a given "period" (microseconds), a group is allowed to consume up to "quota"
+microseconds of CPU time, which is the upper limit or the hard limit. When the
+CPU bandwidth consumption of a group exceeds the hard limit, the tasks in the
+group are throttled and are not allowed to run until the end of the period at
+which time the group's quota is replenished.
+
+Runtime available to the group is tracked globally. At the beginning of
+every period, group's global runtime pool is replenished with "quota"
+microseconds worth of runtime. The runtime consumption happens locally at each
+CPU by fetching runtimes in "slices" from the global pool.
+
+Interface
+---------
+Quota and period can be set via cgroup files.
+
+cpu.cfs_quota_us: the enforcement interval (microseconds)
+cpu.cfs_period_us: the maximum allowed bandwidth (microseconds)
+
+Within a period of cpu.cfs_period_us, the group as a whole will not be allowed
+to consume more than cpu_cfs_quota_us worth of runtime.
+
+The default value of cpu.cfs_period_us is 500ms and the default value
+for cpu.cfs_quota_us is -1.
+
+A group with cpu.cfs_quota_us as -1 indicates that the group has infinite
+bandwidth, which means that it is not bandwidth controlled.
+
+Writing any negative value to cpu.cfs_quota_us will turn the group into
+an infinite bandwidth group. Reading cpu.cfs_quota_us for an infinite
+bandwidth group will always return -1.
+
+System wide settings
+--------------------
+The amount of runtime obtained from global pool every time a CPU wants the
+group quota locally is controlled by a sysctl parameter
+sched_cfs_bandwidth_slice_us. The current default is 10ms. This can be changed
+by writing to /proc/sys/kernel/sched_cfs_bandwidth_slice_us.
+
+Statistics
+----------
+cpu.stat file lists three different stats related to CPU bandwidth control.
+
+nr_periods: Number of enforcement intervals that have elapsed.
+nr_throttled: Number of times the group has been throttled/limited.
+throttled_time: The total time duration (in nanoseconds) for which the group
+remained throttled.
+
+These files are read-only.
+
+Hierarchy considerations
+------------------------
+Each group's bandwidth (quota and period) can be set independent of its
+parent or child groups. There are two ways in which a group can get
+throttled:
+
+- it consumed its quota within the period
+- it has quota left but the parent's quota is exhausted.
+
+In the 2nd case, even though the child has quota left, it will not be
+able to run since the parent itself is throttled. Similarly groups that are
+not bandwidth constrained might end up being throttled if any parent
+in their hierarchy is throttled.
+
+Examples
+--------
+1. Limit a group to 1 CPU worth of runtime.
+
+	If period is 500ms and quota is also 500ms, the group will get
+	1 CPU worth of runtime every 500ms.
+
+	# echo 500000 > cpu.cfs_quota_us /* quota = 500ms */
+	# echo 500000 > cpu.cfs_period_us /* period = 500ms */
+
+2. Limit a group to 2 CPUs worth of runtime on a multi-CPU machine.
+
+	With 500ms period and 1000ms quota, the group can get 2 CPUs worth of
+	runtime every 500ms.
+
+	# echo 1000000 > cpu.cfs_quota_us /* quota = 1000ms */
+	# echo 500000 > cpu.cfs_period_us /* period = 500ms */
+
+3. Limit a group to 20% of 1 CPU.
+
+	With 500ms period, 100ms quota will be equivalent to 20% of 1 CPU.
+
+	# echo 100000 > cpu.cfs_quota_us /* quota = 100ms */
+	# echo 500000 > cpu.cfs_period_us /* period = 500ms */
#1 lore raw

PATCH v4 1/7 sched: introduce primitives to account for CFS bandwidth tracking

In reply to Paul Turner

In this patch we introduce the notion of CFS bandwidth, to account for the realities of SMP this is partitioned into globally unassigned bandwidth, and locally claimed bandwidth:
- The global bandwidth is per task_group, it represents a pool of unclaimed bandwidth that cfs_rq's can allocate from. It uses the new cfs_bandwidth structure.
- The local bandwidth is tracked per-cfs_rq, this represents allotments from the global pool
bandwidth assigned to a task_group, this is tracked using the new cfs_bandwidth structure.

Bandwidth is managed via cgroupfs via two new files in the cpu subsystem:
- cpu.cfs_period_us : the bandwidth period in usecs
- cpu.cfs_quota_us : the cpu bandwidth (in usecs) that this tg will be allowed to consume over period above.

A per-cfs_bandwidth timer is also introduced to handle future refresh at period expiration. There's some minor refactoring here so that start_bandwidth_timer() functionality can be shared

---
 init/Kconfig        |    9 +
 kernel/sched.c      |  264 +++++++++++++++++++++++++++++++++++++++++++++++-----
 kernel/sched_fair.c |   19 +++
 3 files changed, 269 insertions(+), 23 deletions(-)
init/Kconfig +9 -0
Index: tip/init/Kconfig
===================================================================
@@ -698,6 +698,15 @@ config FAIR_GROUP_SCHED
 	depends on CGROUP_SCHED
 	default CGROUP_SCHED
 
+config CFS_BANDWIDTH
+	bool "CPU bandwidth provisioning for FAIR_GROUP_SCHED"
+	depends on EXPERIMENTAL
+	depends on FAIR_GROUP_SCHED
+	default n
+	help
+	  This option allows users to define quota and period for cpu
+	  bandwidth provisioning on a per-cgroup basis.
+
 config RT_GROUP_SCHED
 	bool "Group scheduling for SCHED_RR/FIFO"
 	depends on EXPERIMENTAL
kernel/sched.c +241 -23

356 lines not on this page · raw message

kernel/sched_fair.c +19 -0
Index: tip/kernel/sched_fair.c
===================================================================
@@ -88,6 +88,15 @@ const_debug unsigned int sysctl_sched_mi
  */
 unsigned int __read_mostly sysctl_sched_shares_window = 10000000UL;
 
+
+#ifdef CONFIG_CFS_BANDWIDTH
+/*
+ * default period for cfs group bandwidth.
+ * default: 0.5s, units: nanoseconds
+ */
+static u64 sched_cfs_bandwidth_period = 500000000ULL;
+#endif
+
 static const struct sched_class fair_sched_class;
 
 /**************************************************************
@@ -397,6 +406,9 @@ static void __enqueue_entity(struct cfs_
 
 	rb_link_node(&se->run_node, parent, link);
 	rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
+#ifdef CONFIG_CFS_BANDWIDTH
+	start_cfs_bandwidth(&cfs_rq->tg->cfs_bandwidth);
+#endif
 }
 
 static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
@@ -1369,6 +1381,13 @@ static void dequeue_task_fair(struct rq 
 	hrtick_update(rq);
 }
 
+#ifdef CONFIG_CFS_BANDWIDTH
+static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
+{
+	return 1;
+}
+#endif
+
 #ifdef CONFIG_SMP
 
 static void task_waking_fair(struct rq *rq, struct task_struct *p)
#49 lore raw

PATCH v4 6/7 sched: hierarchical task accounting for SCHED_OTHER

In reply to Paul Turner

With task entities participating in throttled sub-trees it is possible for task activation/de-activation to not lead to root visible changes to rq->nr_running. This in turn leads to incorrect idle and weight-per-task load balance decisions.

To allow correct accounting we move responsibility for updating rq->nr_running to the respective sched::classes. In the fair-group case this update is hierarchical, tracking the number of active tasks rooted at each group entity.

Note: technically this issue also exists with the existing sched_rt throttling; however due to the nearly complete provisioning of system resources for rt scheduling this is much less common by default.

---
 kernel/sched.c      |    9 ++++++---
 kernel/sched_fair.c |   42 ++++++++++++++++++++++++++++++++++++++++++
 kernel/sched_rt.c   |    5 ++++-
 3 files changed, 52 insertions(+), 4 deletions(-)
kernel/sched.c +6 -3
Index: tip/kernel/sched.c
===================================================================
@@ -330,7 +330,7 @@ struct task_group root_task_group;
 /* CFS-related fields in a runqueue */
 struct cfs_rq {
 	struct load_weight load;
-	unsigned long nr_running;
+	unsigned long nr_running, h_nr_tasks;
 
 	u64 exec_clock;
 	u64 min_vruntime;
@@ -1846,6 +1846,11 @@ static const struct sched_class rt_sched
 
 #include "sched_stats.h"
 
+static void mod_nr_running(struct rq *rq, long delta)
+{
+	rq->nr_running += delta;
+}
+
 static void inc_nr_running(struct rq *rq)
 {
 	rq->nr_running++;
@@ -1896,7 +1901,6 @@ static void activate_task(struct rq *rq,
 		rq->nr_uninterruptible--;
 
 	enqueue_task(rq, p, flags);
-	inc_nr_running(rq);
 }
 
 /*
@@ -1908,7 +1912,6 @@ static void deactivate_task(struct rq *r
 		rq->nr_uninterruptible++;
 
 	dequeue_task(rq, p, flags);
-	dec_nr_running(rq);
 }
 
 #ifdef CONFIG_IRQ_TIME_ACCOUNTING
kernel/sched_fair.c +42 -0

84 lines not on this page · raw message

kernel/sched_rt.c +4 -1
Index: tip/kernel/sched_rt.c
===================================================================
@@ -906,6 +906,8 @@ enqueue_task_rt(struct rq *rq, struct ta
 
 	if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
 		enqueue_pushable_task(rq, p);
+
+	inc_nr_running(rq);
 }
 
 static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
@@ -916,6 +918,8 @@ static void dequeue_task_rt(struct rq *r
 	dequeue_rt_entity(rt_se);
 
 	dequeue_pushable_task(rq, p);
+
+	dec_nr_running(rq);
 }
 
 /*
@@ -1783,4 +1787,3 @@ static void print_rt_stats(struct seq_fi
 	rcu_read_unlock();
 }
 #endif /* CONFIG_SCHED_DEBUG */
-
Acked-by on v4 1/7
#2 lore raw

Re: [CFS Bandwidth Control v4 1/7] sched: introduce primitives to account for CFS bandwidth tracking

In reply to Paul Turner
Quoted 16 lines · Paul Turner

In this patch we introduce the notion of CFS bandwidth, to account for the realities of SMP this is partitioned into globally unassigned bandwidth, and locally claimed bandwidth:
- The global bandwidth is per task_group, it represents a pool of unclaimed bandwidth that cfs_rq's can allocate from. It uses the new cfs_bandwidth structure.
- The local bandwidth is tracked per-cfs_rq, this represents allotments from the global pool
bandwidth assigned to a task_group, this is tracked using the new cfs_bandwidth structure.

Bandwidth is managed via cgroupfs via two new files in the cpu subsystem:
- cpu.cfs_period_us : the bandwidth period in usecs
- cpu.cfs_quota_us : the cpu bandwidth (in usecs) that this tg will be allowed to consume over period above.

Quoted 8 lines

A per-cfs_bandwidth timer is also introduced to handle future refresh at period expiration. There's some minor refactoring here so that start_bandwidth_timer() functionality can be shared

---

Looks good, minor nits below

Quoted 130 lines
 init/Kconfig        |    9 +
 kernel/sched.c      |  264 +++++++++++++++++++++++++++++++++++++++++++++++-----
 kernel/sched_fair.c |   19 +++
 3 files changed, 269 insertions(+), 23 deletions(-)

Index: tip/init/Kconfig
===================================================================

init/Kconfig +9 -0
@@ -698,6 +698,15 @@ config FAIR_GROUP_SCHED
 	depends on CGROUP_SCHED
 	default CGROUP_SCHED
 
+config CFS_BANDWIDTH
+	bool "CPU bandwidth provisioning for FAIR_GROUP_SCHED"
+	depends on EXPERIMENTAL
+	depends on FAIR_GROUP_SCHED
+	default n
+	help
+	  This option allows users to define quota and period for cpu
+	  bandwidth provisioning on a per-cgroup basis.
+
 config RT_GROUP_SCHED
 	bool "Group scheduling for SCHED_RR/FIFO"
 	depends on EXPERIMENTAL

Index: tip/kernel/sched.c
===================================================================

kernel/sched.c +46 -18
@@ -194,10 +194,28 @@ static inline int rt_bandwidth_enabled(v
 	return sysctl_sched_rt_runtime >= 0;
 }
 
-static void start_rt_bandwidth(struct rt_bandwidth *rt_b)
+static void start_bandwidth_timer(struct hrtimer *period_timer, ktime_t period)
 {
-	ktime_t now;
+	unsigned long delta;
+	ktime_t soft, hard, now;
+
+	for (;;) {
+		if (hrtimer_active(period_timer))
+			break;
 
+		now = hrtimer_cb_get_time(period_timer);
+		hrtimer_forward(period_timer, now, period);
+
+		soft = hrtimer_get_softexpires(period_timer);
+		hard = hrtimer_get_expires(period_timer);
+		delta = ktime_to_ns(ktime_sub(hard, soft));
+		__hrtimer_start_range_ns(period_timer, soft, delta,
+					 HRTIMER_MODE_ABS_PINNED, 0);
+	}
+}
+
+static void start_rt_bandwidth(struct rt_bandwidth *rt_b)
+{
 	if (!rt_bandwidth_enabled() || rt_b->rt_runtime == RUNTIME_INF)
 		return;
 
@@ -205,22 +223,7 @@ static void start_rt_bandwidth(struct rt
 		return;
 
 	raw_spin_lock(&rt_b->rt_runtime_lock);
-	for (;;) {
-		unsigned long delta;
-		ktime_t soft, hard;
-
-		if (hrtimer_active(&rt_b->rt_period_timer))
-			break;
-
-		now = hrtimer_cb_get_time(&rt_b->rt_period_timer);
-		hrtimer_forward(&rt_b->rt_period_timer, now, rt_b->rt_period);
-
-		soft = hrtimer_get_softexpires(&rt_b->rt_period_timer);
-		hard = hrtimer_get_expires(&rt_b->rt_period_timer);
-		delta = ktime_to_ns(ktime_sub(hard, soft));
-		__hrtimer_start_range_ns(&rt_b->rt_period_timer, soft, delta,
-				HRTIMER_MODE_ABS_PINNED, 0);
-	}
+	start_bandwidth_timer(&rt_b->rt_period_timer, rt_b->rt_period);
 	raw_spin_unlock(&rt_b->rt_runtime_lock);
 }
 
@@ -245,6 +248,15 @@ struct cfs_rq;
 
 static LIST_HEAD(task_groups);
 
+#ifdef CONFIG_CFS_BANDWIDTH
+struct cfs_bandwidth {
+	raw_spinlock_t		lock;
+	ktime_t			period;
+	u64			runtime, quota;
+	struct hrtimer		period_timer;
+};
+#endif
+
 /* task group related information */
 struct task_group {
 	struct cgroup_subsys_state css;
@@ -276,6 +288,10 @@ struct task_group {
 #ifdef CONFIG_SCHED_AUTOGROUP
 	struct autogroup *autogroup;
 #endif
+
+#ifdef CONFIG_CFS_BANDWIDTH
+	struct cfs_bandwidth cfs_bandwidth;
+#endif
 };
 
 /* task_group_lock serializes the addition/removal of task groups */
@@ -370,9 +386,76 @@ struct cfs_rq {
 
 	unsigned long load_contribution;
 #endif
+#ifdef CONFIG_CFS_BANDWIDTH
+	u64 quota_assigned, quota_used;
+#endif
 #endif
 };
 
+#ifdef CONFIG_CFS_BANDWIDTH
+static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun);
+
+static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
+{
+	struct cfs_bandwidth *cfs_b =
+		container_of(timer, struct cfs_bandwidth, period_timer);
+	ktime_t now;
+	int overrun;

kernel/sched.c struct cfs_rq { · line 413

Quoted 10 lines
kernel/sched.c +10 -0
+	int idle = 0;
+
+	for (;;) {
+		now = hrtimer_cb_get_time(timer);
+		overrun = hrtimer_forward(timer, now, cfs_b->period);
+
+		if (!overrun)
+			break;
+
+		idle = do_sched_cfs_period_timer(cfs_b, overrun);

This patch just sets up to return do_sched_cfs_period_timer to return
1. I am afraid I don't understand why this function is introduced here.

Quoted 141 lines
kernel/sched.c +81 -4
+	}
+
+	return idle ? HRTIMER_NORESTART : HRTIMER_RESTART;
+}
+
+static
+void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b, u64 quota, u64 period)
+{
+	raw_spin_lock_init(&cfs_b->lock);
+	cfs_b->quota = cfs_b->runtime = quota;
+	cfs_b->period = ns_to_ktime(period);
+
+	hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+	cfs_b->period_timer.function = sched_cfs_period_timer;
+}
+
+static
+void init_cfs_rq_quota(struct cfs_rq *cfs_rq)
+{
+	cfs_rq->quota_used = 0;
+	if (cfs_rq->tg->cfs_bandwidth.quota == RUNTIME_INF)
+		cfs_rq->quota_assigned = RUNTIME_INF;
+	else
+		cfs_rq->quota_assigned = 0;
+}
+
+static void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+	if (cfs_b->quota == RUNTIME_INF)
+		return;
+
+	if (hrtimer_active(&cfs_b->period_timer))
+		return;
+
+	raw_spin_lock(&cfs_b->lock);
+	start_bandwidth_timer(&cfs_b->period_timer, cfs_b->period);
+	raw_spin_unlock(&cfs_b->lock);
+}
+
+static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+	hrtimer_cancel(&cfs_b->period_timer);
+}
+#endif
+
 /* Real-Time classes' related field in a runqueue: */
 struct rt_rq {
 	struct rt_prio_array active;
@@ -8038,6 +8121,9 @@ static void init_tg_cfs_entry(struct tas
 	tg->cfs_rq[cpu] = cfs_rq;
 	init_cfs_rq(cfs_rq, rq);
 	cfs_rq->tg = tg;
+#ifdef CONFIG_CFS_BANDWIDTH
+	init_cfs_rq_quota(cfs_rq);
+#endif
 
 	tg->se[cpu] = se;
 	/* se could be NULL for root_task_group */
@@ -8173,6 +8259,10 @@ void __init sched_init(void)
 		 * We achieve this by letting root_task_group's tasks sit
 		 * directly in rq->cfs (i.e root_task_group->se[] = NULL).
 		 */
+#ifdef CONFIG_CFS_BANDWIDTH
+		init_cfs_bandwidth(&root_task_group.cfs_bandwidth,
+				RUNTIME_INF, sched_cfs_bandwidth_period);
+#endif
 		init_tg_cfs_entry(&root_task_group, &rq->cfs, NULL, i, NULL);
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
@@ -8415,6 +8505,10 @@ static void free_fair_sched_group(struct
 {
 	int i;
 
+#ifdef CONFIG_CFS_BANDWIDTH
+	destroy_cfs_bandwidth(&tg->cfs_bandwidth);
+#endif
+
 	for_each_possible_cpu(i) {
 		if (tg->cfs_rq)
 			kfree(tg->cfs_rq[i]);
@@ -8442,7 +8536,10 @@ int alloc_fair_sched_group(struct task_g
 		goto err;
 
 	tg->shares = NICE_0_LOAD;
-
+#ifdef CONFIG_CFS_BANDWIDTH
+	init_cfs_bandwidth(&tg->cfs_bandwidth, RUNTIME_INF,
+			sched_cfs_bandwidth_period);
+#endif
 	for_each_possible_cpu(i) {
 		rq = cpu_rq(i);
 
@@ -8822,7 +8919,7 @@ static int __rt_schedulable(struct task_
 	return walk_tg_tree(tg_schedulable, tg_nop, &data);
 }
 
-static int tg_set_bandwidth(struct task_group *tg,
+static int tg_set_rt_bandwidth(struct task_group *tg,
 		u64 rt_period, u64 rt_runtime)
 {
 	int i, err = 0;
@@ -8861,7 +8958,7 @@ int sched_group_set_rt_runtime(struct ta
 	if (rt_runtime_us < 0)
 		rt_runtime = RUNTIME_INF;
 
-	return tg_set_bandwidth(tg, rt_period, rt_runtime);
+	return tg_set_rt_bandwidth(tg, rt_period, rt_runtime);
 }
 
 long sched_group_rt_runtime(struct task_group *tg)
@@ -8886,7 +8983,7 @@ int sched_group_set_rt_period(struct tas
 	if (rt_period == 0)
 		return -EINVAL;
 
-	return tg_set_bandwidth(tg, rt_period, rt_runtime);
+	return tg_set_rt_bandwidth(tg, rt_period, rt_runtime);
 }
 
 long sched_group_rt_period(struct task_group *tg)
@@ -9107,6 +9204,116 @@ static u64 cpu_shares_read_u64(struct cg
 
 	return (u64) tg->shares;
 }
+
+#ifdef CONFIG_CFS_BANDWIDTH
+static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
+{
+	int i;
+	static DEFINE_MUTEX(mutex);
+
+	if (tg == &root_task_group)
+		return -EINVAL;
+
+	if (!period)
+		return -EINVAL;
+
+	/*
+	 * Ensure we have at least one tick of bandwidth every period.  This is
+	 * to prevent reaching a state of large arrears when throttled via
+	 * entity_tick() resulting in prolonged exit starvation.
+	 */

kernel/sched.c static u64 cpu_shares_read_u64(struct cg · line 9234

Quoted 10 lines
kernel/sched.c +10 -0
+	if (NS_TO_JIFFIES(quota) < 1)
+		return -EINVAL;
+
+	mutex_lock(&mutex);
+	raw_spin_lock_irq(&tg->cfs_bandwidth.lock);
+	tg->cfs_bandwidth.period = ns_to_ktime(period);
+	tg->cfs_bandwidth.runtime = tg->cfs_bandwidth.quota = quota;
+	raw_spin_unlock_irq(&tg->cfs_bandwidth.lock);
+
+	for_each_possible_cpu(i) {

Why for each possible cpu - to avoid hotplug handling?

Quoted 155 lines
kernel/sched.c +94 -1
+		struct cfs_rq *cfs_rq = tg->cfs_rq[i];
+		struct rq *rq = rq_of(cfs_rq);
+
+		raw_spin_lock_irq(&rq->lock);
+		init_cfs_rq_quota(cfs_rq);
+		raw_spin_unlock_irq(&rq->lock);
+	}
+	mutex_unlock(&mutex);
+
+	return 0;
+}
+
+int tg_set_cfs_quota(struct task_group *tg, long cfs_runtime_us)
+{
+	u64 quota, period;
+
+	period = ktime_to_ns(tg->cfs_bandwidth.period);
+	if (cfs_runtime_us < 0)
+		quota = RUNTIME_INF;
+	else
+		quota = (u64)cfs_runtime_us * NSEC_PER_USEC;
+
+	return tg_set_cfs_bandwidth(tg, period, quota);
+}
+
+long tg_get_cfs_quota(struct task_group *tg)
+{
+	u64 quota_us;
+
+	if (tg->cfs_bandwidth.quota == RUNTIME_INF)
+		return -1;
+
+	quota_us = tg->cfs_bandwidth.quota;
+	do_div(quota_us, NSEC_PER_USEC);
+	return quota_us;
+}
+
+int tg_set_cfs_period(struct task_group *tg, long cfs_period_us)
+{
+	u64 quota, period;
+
+	period = (u64)cfs_period_us * NSEC_PER_USEC;
+	quota = tg->cfs_bandwidth.quota;
+
+	if (period <= 0)
+		return -EINVAL;
+
+	return tg_set_cfs_bandwidth(tg, period, quota);
+}
+
+long tg_get_cfs_period(struct task_group *tg)
+{
+	u64 cfs_period_us;
+
+	cfs_period_us = ktime_to_ns(tg->cfs_bandwidth.period);
+	do_div(cfs_period_us, NSEC_PER_USEC);
+	return cfs_period_us;
+}
+
+static s64 cpu_cfs_quota_read_s64(struct cgroup *cgrp, struct cftype *cft)
+{
+	return tg_get_cfs_quota(cgroup_tg(cgrp));
+}
+
+static int cpu_cfs_quota_write_s64(struct cgroup *cgrp, struct cftype *cftype,
+				s64 cfs_quota_us)
+{
+	return tg_set_cfs_quota(cgroup_tg(cgrp), cfs_quota_us);
+}
+
+static u64 cpu_cfs_period_read_u64(struct cgroup *cgrp, struct cftype *cft)
+{
+	return tg_get_cfs_period(cgroup_tg(cgrp));
+}
+
+static int cpu_cfs_period_write_u64(struct cgroup *cgrp, struct cftype *cftype,
+				u64 cfs_period_us)
+{
+	return tg_set_cfs_period(cgroup_tg(cgrp), cfs_period_us);
+}
+
+#endif /* CONFIG_CFS_BANDWIDTH */
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
 #ifdef CONFIG_RT_GROUP_SCHED
@@ -9141,6 +9348,18 @@ static struct cftype cpu_files[] = {
 		.write_u64 = cpu_shares_write_u64,
 	},
 #endif
+#ifdef CONFIG_CFS_BANDWIDTH
+	{
+		.name = "cfs_quota_us",
+		.read_s64 = cpu_cfs_quota_read_s64,
+		.write_s64 = cpu_cfs_quota_write_s64,
+	},
+	{
+		.name = "cfs_period_us",
+		.read_u64 = cpu_cfs_period_read_u64,
+		.write_u64 = cpu_cfs_period_write_u64,
+	},
+#endif
 #ifdef CONFIG_RT_GROUP_SCHED
 	{
 		.name = "rt_runtime_us",
@@ -9450,4 +9669,3 @@ struct cgroup_subsys cpuacct_subsys = {
 	.subsys_id = cpuacct_subsys_id,
 };
 #endif	/* CONFIG_CGROUP_CPUACCT */
-

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +19 -0
@@ -88,6 +88,15 @@ const_debug unsigned int sysctl_sched_mi
  */
 unsigned int __read_mostly sysctl_sched_shares_window = 10000000UL;
 
+
+#ifdef CONFIG_CFS_BANDWIDTH
+/*
+ * default period for cfs group bandwidth.
+ * default: 0.5s, units: nanoseconds
+ */
+static u64 sched_cfs_bandwidth_period = 500000000ULL;
+#endif
+
 static const struct sched_class fair_sched_class;
 
 /**************************************************************
@@ -397,6 +406,9 @@ static void __enqueue_entity(struct cfs_
 
 	rb_link_node(&se->run_node, parent, link);
 	rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
+#ifdef CONFIG_CFS_BANDWIDTH
+	start_cfs_bandwidth(&cfs_rq->tg->cfs_bandwidth);
+#endif
 }
 
 static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
@@ -1369,6 +1381,13 @@ static void dequeue_task_fair(struct rq 
 	hrtick_update(rq);
 }
 
+#ifdef CONFIG_CFS_BANDWIDTH
+static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
+{
+	return 1;
+}
+#endif
+
 #ifdef CONFIG_SMP
 
 static void task_waking_fair(struct rq *rq, struct task_struct *p)
Signature · 2 lines
	Three Cheers,
	Balbir
Acked-by on v4 2/7
#8 lore raw

Re: [CFS Bandwidth Control v4 2/7] sched: accumulate per-cfs_rq cpu usage

In reply to Paul Turner
Quoted 10 lines · Paul Turner

Introduce account_cfs_rq_quota() to account bandwidth usage on the cfs_rq level versus task_groups for which bandwidth has been assigned. This is tracked by whether the local cfs_rq->quota_assigned is finite or infinite (RUNTIME_INF).

For cfs_rq's that belong to a bandwidth constrained task_group we introduce tg_request_cfs_quota() which attempts to allocate quota from the global pool for use locally. Updates involving the global pool are currently protected under cfs_bandwidth->lock, local pools are protected by rq->lock.

Quoted 7 lines

This patch only attempts to assign and track quota, no action is taken in the case that cfs_rq->quota_used exceeds cfs_rq->quota_assigned.

---

Signature · 2 lines
	Three Cheers,
	Balbir
#3 lore raw

Re: [CFS Bandwidth Control v4 1/7] sched: introduce primitives to account for CFS bandwidth tracking

In reply to Balbir Singh
Quoted 27 lines · Balbir Singh
Quoted 16 lines · Paul Turner

In this patch we introduce the notion of CFS bandwidth, to account for the realities of SMP this is partitioned into globally unassigned bandwidth, and locally claimed bandwidth:
- The global bandwidth is per task_group, it represents a pool of unclaimed bandwidth that cfs_rq's can allocate from. It uses the new cfs_bandwidth structure.
- The local bandwidth is tracked per-cfs_rq, this represents allotments from the global pool
bandwidth assigned to a task_group, this is tracked using the new cfs_bandwidth structure.

Bandwidth is managed via cgroupfs via two new files in the cpu subsystem:
- cpu.cfs_period_us : the bandwidth period in usecs
- cpu.cfs_quota_us : the cpu bandwidth (in usecs) that this tg will be allowed to consume over period above.

Quoted 8 lines

A per-cfs_bandwidth timer is also introduced to handle future refresh at period expiration. There's some minor refactoring here so that start_bandwidth_timer() functionality can be shared

---

Quoted 4 lines

Looks good, minor nits below

Thanks Balbir.

Quoted 13 lines
Quoted 13 lines
kernel/sched.c +13 -0
+
+static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
+{
+	struct cfs_bandwidth *cfs_b =
+		container_of(timer, struct cfs_bandwidth, period_timer);
+	ktime_t now;
+	int overrun;
+	int idle = 0;
+
+	for (;;) {
+		now = hrtimer_cb_get_time(timer);
+		overrun = hrtimer_forward(timer, now, cfs_b->period);
+
Quoted 8 lines

kernel/sched.c struct cfs_rq { · line 413

Quoted 4 lines
kernel/sched.c +4 -0
+		if (!overrun)
+			break;
+
+		idle = do_sched_cfs_period_timer(cfs_b, overrun);

This patch just sets up to return do_sched_cfs_period_timer to return
1. I am afraid I don't understand why this function is introduced here.

Answered this during last post: http://lkml.org/lkml/2010/10/14/31

Quoted 10 lines

kernel/sched.c static u64 cpu_shares_read_u64(struct cg · line 9234

Quoted 8 lines
kernel/sched.c +8 -0
+
+	mutex_lock(&mutex);
+	raw_spin_lock_irq(&tg->cfs_bandwidth.lock);
+	tg->cfs_bandwidth.period = ns_to_ktime(period);
+	tg->cfs_bandwidth.runtime = tg->cfs_bandwidth.quota = quota;
+	raw_spin_unlock_irq(&tg->cfs_bandwidth.lock);
+
+	for_each_possible_cpu(i) {

Why for each possible cpu - to avoid hotplug handling?

Touched upon this during last post: https://lkml.org/lkml/2010/12/6/49

Regards,
Bharata.

Acked-by on v4 3/7
#13 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Paul Turner
Quoted 17 lines · Paul Turner

In account_cfs_rq_quota() (via update_curr()) we track consumption versus a cfs_rq's local quota and whether there is global quota available to continue enabling it in the event we run out.

This patch adds the required support for the latter case, throttling entities until quota is available to run. Throttling dequeues the entity in question and sends a reschedule to the owning cpu so that it can be evicted.

The following restrictions apply to a throttled cfs_rq:
- It is dequeued from sched_entity hierarchy and restricted from being re-enqueued. This means that new/waking children of this entity will be queued up to it, but not past it.
- It does not contribute to weight calculations in tg_shares_up
- In the case that the cfs_rq of the cpu we are trying to pull from is throttled it is is ignored by the loadbalancer in __load_balance_fair() and move_one_task_fair().

Quoted 3 lines
Signature · 2 lines
	Three Cheers,
	Balbir
#33 lore raw

Re: [CFS Bandwidth Control v4 4/7] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

In reply to Paul Turner
Quoted 133 lines · Paul Turner

At the start of a new period there are several actions we must take:
- Refresh global bandwidth pool
- Unthrottle entities who ran out of quota as refreshed bandwidth permits

Unthrottled entities have the cfs_rq->throttled flag set and are re-enqueued into the cfs entity hierarchy.

sched_rt_period_mask() is refactored slightly into sched_bw_period_mask() since it is now shared by both cfs and rt bandwidth period timers.

The !CONFIG_RT_GROUP_SCHED && CONFIG_SMP case has been collapsed to use rd->span instead of cpu_online_mask since I think that was incorrect before (don't want to hit cpu's outside of your root_domain for RT bandwidth).

---
 kernel/sched.c      |   16 +++++++++++
 kernel/sched_fair.c |   74 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 kernel/sched_rt.c   |   19 -------------
 3 files changed, 90 insertions(+), 19 deletions(-)

Index: tip/kernel/sched.c
===================================================================

kernel/sched.c +16 -0
@@ -1561,6 +1561,8 @@ static int tg_nop(struct task_group *tg,
 }
 #endif
 
+static inline const struct cpumask *sched_bw_period_mask(void);
+
 #ifdef CONFIG_SMP
 /* Used instead of source_load when we know the type == 0 */
 static unsigned long weighted_cpuload(const int cpu)
@@ -8503,6 +8505,18 @@ void set_curr_task(int cpu, struct task_
 
 #endif
 
+#ifdef CONFIG_SMP
+static inline const struct cpumask *sched_bw_period_mask(void)
+{
+	return cpu_rq(smp_processor_id())->rd->span;
+}
+#else
+static inline const struct cpumask *sched_bw_period_mask(void)
+{
+	return cpu_online_mask;
+}
+#endif
+
 #ifdef CONFIG_FAIR_GROUP_SCHED
 static void free_fair_sched_group(struct task_group *tg)
 {
@@ -9240,6 +9254,8 @@ static int tg_set_cfs_bandwidth(struct t
 
 		raw_spin_lock_irq(&rq->lock);
 		init_cfs_rq_quota(cfs_rq);
+		if (cfs_rq_throttled(cfs_rq))
+			unthrottle_cfs_rq(cfs_rq);
 		raw_spin_unlock_irq(&rq->lock);
 	}
 	mutex_unlock(&mutex);

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +46 -1
@@ -327,6 +327,13 @@ static inline u64 sched_cfs_bandwidth_sl
 	return (u64)sysctl_sched_cfs_bandwidth_slice * NSEC_PER_USEC;
 }
 
+static inline
+struct cfs_rq *cfs_bandwidth_cfs_rq(struct cfs_bandwidth *cfs_b, int cpu)
+{
+	return container_of(cfs_b, struct task_group,
+			cfs_bandwidth)->cfs_rq[cpu];
+}
+
 static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg)
 {
 	return &tg->cfs_bandwidth;
@@ -1513,6 +1520,33 @@ out_throttled:
 	update_cfs_rq_load_contribution(cfs_rq, 1);
 }
 
+static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+	struct rq *rq = rq_of(cfs_rq);
+	struct sched_entity *se;
+
+	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+	update_rq_clock(rq);
+	/* (Try to) avoid maintaining share statistics for idle time */
+	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;
+
+	cfs_rq->throttled = 0;
+	for_each_sched_entity(se) {
+		if (se->on_rq)
+			break;
+
+		cfs_rq = cfs_rq_of(se);
+		enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
+		if (cfs_rq_throttled(cfs_rq))
+			break;
+	}
+
+	/* determine whether we need to wake up potentally idle cpu */
+	if (rq->curr == rq->idle && rq->cfs.nr_running)
+		resched_task(rq->curr);
+}
+
 static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
 		unsigned long delta_exec)
 {
@@ -1535,8 +1569,46 @@ static void account_cfs_rq_quota(struct 
 
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
 {
-	return 1;
+	int i, idle = 1;
+	u64 delta;
+	const struct cpumask *span;
+
+	if (cfs_b->quota == RUNTIME_INF)
+		return 1;
+
+	/* reset group quota */
+	raw_spin_lock(&cfs_b->lock);
+	cfs_b->runtime = cfs_b->quota;
+	raw_spin_unlock(&cfs_b->lock);
+

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1593

Quoted 10 lines
kernel/sched_fair.c +10 -0
+	span = sched_bw_period_mask();
+	for_each_cpu(i, span) {
+		struct rq *rq = cpu_rq(i);
+		struct cfs_rq *cfs_rq = cfs_bandwidth_cfs_rq(cfs_b, i);
+
+		if (cfs_rq->nr_running)
+			idle = 0;
+
+		if (!cfs_rq_throttled(cfs_rq))
+			continue;

This is an interesting situation, does this mean we got scheduled in between periods with quota to last us enough to cross the period. Should we be donating quota back to the global pool?

Quoted 67 lines
kernel/sched_fair.c +17 -0
+
+		delta = tg_request_cfs_quota(cfs_rq->tg);
+
+		if (delta) {
+			raw_spin_lock(&rq->lock);
+			cfs_rq->quota_assigned += delta;
+
+			/* avoid race with tg_set_cfs_bandwidth */
+			if (cfs_rq_throttled(cfs_rq) &&
+			     cfs_rq->quota_used < cfs_rq->quota_assigned)
+				unthrottle_cfs_rq(cfs_rq);
+			raw_spin_unlock(&rq->lock);
+		}
+	}
+
+	return idle;
 }
+
 #endif
 
 #ifdef CONFIG_SMP

Index: tip/kernel/sched_rt.c
===================================================================

kernel/sched_rt.c +1 -18
@@ -252,18 +252,6 @@ static int rt_se_boosted(struct sched_rt
 	return p->prio != p->normal_prio;
 }
 
-#ifdef CONFIG_SMP
-static inline const struct cpumask *sched_rt_period_mask(void)
-{
-	return cpu_rq(smp_processor_id())->rd->span;
-}
-#else
-static inline const struct cpumask *sched_rt_period_mask(void)
-{
-	return cpu_online_mask;
-}
-#endif
-
 static inline
 struct rt_rq *sched_rt_period_rt_rq(struct rt_bandwidth *rt_b, int cpu)
 {
@@ -321,11 +309,6 @@ static inline int rt_rq_throttled(struct
 	return rt_rq->rt_throttled;
 }
 
-static inline const struct cpumask *sched_rt_period_mask(void)
-{
-	return cpu_online_mask;
-}
-
 static inline
 struct rt_rq *sched_rt_period_rt_rq(struct rt_bandwidth *rt_b, int cpu)
 {
@@ -543,7 +526,7 @@ static int do_sched_rt_period_timer(stru
 	if (!rt_bandwidth_enabled() || rt_b->rt_runtime == RUNTIME_INF)
 		return 1;
 
-	span = sched_rt_period_mask();
+	span = sched_bw_period_mask();
 	for_each_cpu(i, span) {
 		int enqueue = 0;
 		struct rt_rq *rt_rq = sched_rt_period_rt_rq(rt_b, i);
Signature · 2 lines
	Three Cheers,
	Balbir
#34 lore raw

Re: [CFS Bandwidth Control v4 4/7] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

Quoted 141 lines · Balbir Singh
Quoted 139 lines · Paul Turner

At the start of a new period there are several actions we must take:
- Refresh global bandwidth pool
- Unthrottle entities who ran out of quota as refreshed bandwidth permits

Unthrottled entities have the cfs_rq->throttled flag set and are re-enqueued into the cfs entity hierarchy.

sched_rt_period_mask() is refactored slightly into sched_bw_period_mask() since it is now shared by both cfs and rt bandwidth period timers.

The !CONFIG_RT_GROUP_SCHED && CONFIG_SMP case has been collapsed to use rd->span instead of cpu_online_mask since I think that was incorrect before (don't want to hit cpu's outside of your root_domain for RT bandwidth).

---
 kernel/sched.c      |   16 +++++++++++
 kernel/sched_fair.c |   74 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 kernel/sched_rt.c   |   19 -------------
 3 files changed, 90 insertions(+), 19 deletions(-)

Index: tip/kernel/sched.c
===================================================================

kernel/sched.c +16 -0
@@ -1561,6 +1561,8 @@ static int tg_nop(struct task_group *tg,
 }
 #endif
 
+static inline const struct cpumask *sched_bw_period_mask(void);
+
 #ifdef CONFIG_SMP
 /* Used instead of source_load when we know the type == 0 */
 static unsigned long weighted_cpuload(const int cpu)
@@ -8503,6 +8505,18 @@ void set_curr_task(int cpu, struct task_
 
 #endif
 
+#ifdef CONFIG_SMP
+static inline const struct cpumask *sched_bw_period_mask(void)
+{
+	return cpu_rq(smp_processor_id())->rd->span;
+}
+#else
+static inline const struct cpumask *sched_bw_period_mask(void)
+{
+	return cpu_online_mask;
+}
+#endif
+
 #ifdef CONFIG_FAIR_GROUP_SCHED
 static void free_fair_sched_group(struct task_group *tg)
 {
@@ -9240,6 +9254,8 @@ static int tg_set_cfs_bandwidth(struct t
 
 		raw_spin_lock_irq(&rq->lock);
 		init_cfs_rq_quota(cfs_rq);
+		if (cfs_rq_throttled(cfs_rq))
+			unthrottle_cfs_rq(cfs_rq);
 		raw_spin_unlock_irq(&rq->lock);
 	}
 	mutex_unlock(&mutex);

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +52 -1
@@ -327,6 +327,13 @@ static inline u64 sched_cfs_bandwidth_sl
 	return (u64)sysctl_sched_cfs_bandwidth_slice * NSEC_PER_USEC;
 }
 
+static inline
+struct cfs_rq *cfs_bandwidth_cfs_rq(struct cfs_bandwidth *cfs_b, int cpu)
+{
+	return container_of(cfs_b, struct task_group,
+			cfs_bandwidth)->cfs_rq[cpu];
+}
+
 static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg)
 {
 	return &tg->cfs_bandwidth;
@@ -1513,6 +1520,33 @@ out_throttled:
 	update_cfs_rq_load_contribution(cfs_rq, 1);
 }
 
+static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+	struct rq *rq = rq_of(cfs_rq);
+	struct sched_entity *se;
+
+	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+	update_rq_clock(rq);
+	/* (Try to) avoid maintaining share statistics for idle time */
+	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;
+
+	cfs_rq->throttled = 0;
+	for_each_sched_entity(se) {
+		if (se->on_rq)
+			break;
+
+		cfs_rq = cfs_rq_of(se);
+		enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
+		if (cfs_rq_throttled(cfs_rq))
+			break;
+	}
+
+	/* determine whether we need to wake up potentally idle cpu */
+	if (rq->curr == rq->idle && rq->cfs.nr_running)
+		resched_task(rq->curr);
+}
+
 static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
 		unsigned long delta_exec)
 {
@@ -1535,8 +1569,46 @@ static void account_cfs_rq_quota(struct 
 
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
 {
-	return 1;
+	int i, idle = 1;
+	u64 delta;
+	const struct cpumask *span;
+
+	if (cfs_b->quota == RUNTIME_INF)
+		return 1;
+
+	/* reset group quota */
+	raw_spin_lock(&cfs_b->lock);
+	cfs_b->runtime = cfs_b->quota;
+	raw_spin_unlock(&cfs_b->lock);
+
+	span = sched_bw_period_mask();
+	for_each_cpu(i, span) {
+		struct rq *rq = cpu_rq(i);
+		struct cfs_rq *cfs_rq = cfs_bandwidth_cfs_rq(cfs_b, i);
+
+		if (cfs_rq->nr_running)
Quoted 8 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1593

Quoted 4 lines
kernel/sched_fair.c +4 -0
+			idle = 0;
+
+		if (!cfs_rq_throttled(cfs_rq))
+			continue;

This is an interesting situation, does this mean we got scheduled in between periods with quota to last us enough to cross the period. Should we be donating quota back to the global pool?

I see 2 possibilities of this happening:

1. The tasks in the group were dequeued (due to sleep) before utilizing the full quota within the period.

2. The tasks in the group couldn't fully utilize the available quota before the period timer fired.

Note that the period timer fires every period as long as the group has active tasks.

In either case, we reset the global pool.

We could potentially return the local slice back to global pool. I had a patch in v3 to cover case 1. But we decided to get the base stuff accepted before having such optimizations.

Regards,
Bharata.

#59 lore raw
In reply to Paul Turner
Quoted 9 lines · Paul Turner

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Thanks for the great features!

I applied the patchset to kvm tree, then tested with kvm guest, unfortunately, it seems don't work normally.

The steps is follow:

# mount -t cgroup -o cpu none /mnt/
# qemu-system-x86_64 -enable-kvm  -smp 4 -m 512M -drive file=fc64.img,index=0,media=disk

Don't do any configuration in cgroup, and run the kvm guest directly (don't use libvirt), the guest booted very slowly and i saw some "soft lockup" bugs reported in the guest, i also noticed one CPU usage is 100% for more than 60s and other CPUs is 10%~30% in the host when guest was booting.

And if cgroup is not mounted, the guest runs well.

The kernel config file is attached and my system cpu info is:

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
stepping	: 5
cpu MHz		: 1197.000
cache size	: 8192 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5584.73
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
stepping : 5
cpu MHz : 1197.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 5585.03
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
stepping : 5
cpu MHz : 1197.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 5585.03
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
stepping : 5
cpu MHz : 1197.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 5585.03
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

#
# Automatically generated make config: don't edit
# Linux/x86_64 2.6.38-rc4 Kernel Configuration
# Mon Feb 21 09:42:01 2011
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" # CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
# CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y
# CONFIG_AUTO_IRQ_AFFINITY is not set
# CONFIG_IRQ_PER_CPU is not set
# CONFIG_HARDIRQS_SW_RESEND is not set CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_PERF_COUNTERS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
CONFIG_OPTPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLK_DEV_THROTTLING=y
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y
# CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set # CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set # CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set # CONFIG_INLINE_READ_UNLOCK_IRQ is not set # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set # CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set # CONFIG_MUTEX_SPIN_ON_OWNER is not set CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_X86_X2APIC=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
# CONFIG_X86_UV is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=7
CONFIG_X86_CMPXCHG=y
CONFIG_CMPXCHG_LOCAL=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_STATS=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_IOMMU_API=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=256
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=9
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_MEMORY_PROBE=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
CONFIG_HWPOISON_INJECT=m
# CONFIG_TRANSPARENT_HUGEPAGE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_EFI=y
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_JUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_PM_ADVANCED_DEBUG=y
# CONFIG_PM_VERBOSE is not set
CONFIG_CAN_PM_TRACE=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_SLEEP_ADVANCED_DEBUG is not set
CONFIG_SUSPEND=y
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_RUNTIME=y
CONFIG_PM_OPS=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_POWER_METER=m
# CONFIG_ACPI_EC_DEBUGFS is not set
# CONFIG_ACPI_PROC_EVENT is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
# CONFIG_ACPI_IPMI is not set
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=m
CONFIG_ACPI_SBS=m
CONFIG_ACPI_HED=m
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=m
# CONFIG_ACPI_APEI_EINJ is not set
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
CONFIG_SFI=y

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_POWERNOW_K8=m
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m

#

# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_INTEL_IDLE=y

#
# Memory power savings
#
CONFIG_I7300_IDLE_IOAT_CHANNEL=y
CONFIG_I7300_IDLE=m

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_DMAR=y
CONFIG_DMAR_DEFAULT_ON=y
CONFIG_DMAR_FLOPPY_WA=y
CONFIG_INTR_REMAP=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIE_PME=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
CONFIG_PCI_STUB=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_HT_IRQ=y
CONFIG_PCI_IOV=y
CONFIG_PCI_IOAPIC=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
# CONFIG_IPV6 is not set
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_MARK=y
# CONFIG_NF_CONNTRACK_SECMARK is not set
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_DCCP is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
# CONFIG_NF_CONNTRACK_FTP is not set
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
# CONFIG_NF_CT_NETLINK is not set
# CONFIG_NETFILTER_TPROXY is not set
CONFIG_NETFILTER_XTABLES=m

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m
CONFIG_NETFILTER_XT_CONNMARK=m

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
# CONFIG_NETFILTER_XT_TARGET_CT is not set
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_LED=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_CPU=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_OSF=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_NF_NAT_SNMP_BASIC=m
# CONFIG_NF_NAT_FTP is not set
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
CONFIG_NET_SCTPPROBE=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
CONFIG_SCTP_HMAC_SHA1=y
# CONFIG_SCTP_HMAC_MD5 is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
CONFIG_NET_DSA_MV88E6131=y
CONFIG_NET_DSA_MV88E6123_61_65=y
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
CONFIG_RPS=y
CONFIG_XPS=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
# CONFIG_PARIDE_ATEN is not set
# CONFIG_PARIDE_BPCK is not set
# CONFIG_PARIDE_COMM is not set
# CONFIG_PARIDE_DSTR is not set
# CONFIG_PARIDE_FIT2 is not set
# CONFIG_PARIDE_FIT3 is not set
# CONFIG_PARIDE_EPAT is not set
# CONFIG_PARIDE_EPIA is not set
# CONFIG_PARIDE_FRIQ is not set
# CONFIG_PARIDE_FRPW is not set
# CONFIG_PARIDE_KBIC is not set
# CONFIG_PARIDE_KTTI is not set
# CONFIG_PARIDE_ON20 is not set
# CONFIG_PARIDE_ON26 is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_OSD is not set
CONFIG_BLK_DEV_SX8=m
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_XEN_BLKDEV_FRONTEND is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_BLK_DEV_RBD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_AD525X_DPOT is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
# CONFIG_TIFM_7XX1 is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_CS5535_MFGPT is not set
# CONFIG_HP_ILO is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_VMWARE_BALLOON is not set
# CONFIG_BMP085 is not set
# CONFIG_PCH_PHUB is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
CONFIG_EEPROM_LEGACY=m
CONFIG_EEPROM_MAX6875=m
CONFIG_EEPROM_93CX6=m
CONFIG_CB710_CORE=m
# CONFIG_CB710_DEBUG is not set
CONFIG_CB710_DEBUG_ASSUMPTIONS=y
# CONFIG_IWMC3200TOP is not set

#
# Texas Instruments shared transport line discipline #
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_ISCSI_BOOT_SYSFS=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_BE2ISCSI=m
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_HPSA=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_3W_SAS=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=4
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC94XX=m
# CONFIG_AIC94XX_DEBUG is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
CONFIG_SCSI_ARCMSR_AER=y
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS_LOGGING=y
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_VMWARE_PVSCSI=m
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
CONFIG_FCOE=m
CONFIG_FCOE_FNIC=m
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
# CONFIG_SCSI_IPR is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_PMCRAID=m
CONFIG_SCSI_PM8001=m
CONFIG_SCSI_SRP=m
CONFIG_SCSI_BFA_FC=m
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
CONFIG_PCMCIA_QLOGIC=m
CONFIG_PCMCIA_SYM53C500=m
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=m
CONFIG_SCSI_DH_HP_SW=m
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_DH_ALUA=m
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=m
CONFIG_SATA_INIC162X=m
# CONFIG_SATA_ACARD_AHCI is not set
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_SX4=m
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_SVW is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OLDPIIX=m
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
CONFIG_PATA_PDC_OLD=m
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SCH=m
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
CONFIG_PATA_SIS=m
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
CONFIG_PATA_MPIIX=m
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
CONFIG_PATA_ACPI=m
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
# CONFIG_MULTICORE_RAID456 is not set
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=y
CONFIG_DM_DEBUG=y
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
# CONFIG_DM_RAID is not set
CONFIG_DM_LOG_USERSPACE=m
CONFIG_DM_ZERO=y
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_QL=m
CONFIG_DM_MULTIPATH_ST=m
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_VETH=m
CONFIG_NET_SB1000=m
# CONFIG_ARCNET is not set
CONFIG_MII=m
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
# CONFIG_BCM63XX_PHY is not set CONFIG_ICPLUS_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_NATIONAL_PHY=m
CONFIG_STE10XP=m
CONFIG_LSI_ET1011C_PHY=m CONFIG_MICREL_PHY=m
CONFIG_FIXED_PHY=y
CONFIG_MDIO_BITBANG=m
# CONFIG_MDIO_GPIO is not set CONFIG_NET_ETHERNET=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_ETHOC is not set
# CONFIG_DNET is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_KSZ884X_PCI is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_ATL2 is not set CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
CONFIG_E1000E=m
# CONFIG_IP1000 is not set
CONFIG_IGB=m
CONFIG_IGB_DCA=y
CONFIG_IGBVF=m
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
CONFIG_BNX2=m
CONFIG_CNIC=m
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_STMMAC_ETH is not set
# CONFIG_PCH_GBE is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers #

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_NET_PCMCIA is not set
# CONFIG_WAN is not set

#
# CAIF transport drivers
#
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
# CONFIG_PPP_ASYNC is not set
# CONFIG_PPP_SYNC_TTY is not set
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_BSDCOMP is not set
# CONFIG_PPP_MPPE is not set
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=m
CONFIG_NET_FC=y
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_VIRTIO_NET=m
CONFIG_VMXNET3=m
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
# CONFIG_XEN_KBDDEV_FRONTEND is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ADP5588=m
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_QT2160=m
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_MAX7359=m
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_OPENCORES=m
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_APANEL=m
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_CM109=m
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_PCF8574 is not set
CONFIG_INPUT_GPIO_ROTARY_ENCODER=m
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
# CONFIG_SERIO_PS2MULT is not set
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_N_HDLC=m
CONFIG_N_GSM=m
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_STALDRV is not set
CONFIG_NOZOMI=m

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_PCH_UART is not set
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_VIRTIO_CONSOLE=m
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_NVRAM=y
CONFIG_R3964=m
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_IPWIRELESS=m
CONFIG_MWAVE=m
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
# CONFIG_RAMOOPS is not set
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_ISCH=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m

#
# ACPI drivers
#
CONFIG_I2C_SCMI=m

#
# I2C system bus drivers (mostly embedded / system-on-chip) #
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_INTEL_MID is not set
# CONFIG_I2C_OCORES is not set CONFIG_I2C_PCA_PLATFORM=m
CONFIG_I2C_SIMTEC=m
# CONFIG_I2C_XILINX is not set
# CONFIG_I2C_EG20T is not set

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_STUB=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#
# CONFIG_PPS_GENERATOR_PARPORT is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO expanders:
#
# CONFIG_GPIO_BASIC_MMIO is not set
# CONFIG_GPIO_IT8761E is not set
CONFIG_GPIO_SCH=m
# CONFIG_GPIO_VX855 is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_ADP5588 is not set

#
# PCI GPIO expanders:
#
# CONFIG_GPIO_CS5535 is not set
CONFIG_GPIO_LANGWELL=y
# CONFIG_GPIO_PCH is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_RDC321X is not set

#
# SPI GPIO expanders:
#

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_BQ20Z75 is not set
CONFIG_BATTERY_BQ27x00=m
CONFIG_BATTERY_MAX17040=m
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_GPIO is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_F71882FG=y
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_PKGTEMP=m
# CONFIG_SENSORS_IBMAEM is not set
# CONFIG_SENSORS_IBMPEX is not set
CONFIG_SENSORS_IT87=y
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_LIS3_I2C is not set
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ATK0110 is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_MFD_SUPPORT=y
CONFIG_MFD_CORE=m
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_UCB1400_CORE is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_CS5535 is not set
# CONFIG_MFD_TIMBERDALE is not set
CONFIG_LPC_SCH=m
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=m

#
# Multimedia core support
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_DVB_CORE=m
CONFIG_VIDEO_MEDIA=m

#
# Multimedia drivers
#
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_RC_CORE=m
CONFIG_LIRC=m
CONFIG_RC_MAP=m
CONFIG_IR_NEC_DECODER=m
CONFIG_IR_RC5_DECODER=m
CONFIG_IR_RC6_DECODER=m
CONFIG_IR_JVC_DECODER=m
CONFIG_IR_SONY_DECODER=m
CONFIG_IR_RC5_SZ_DECODER=m
CONFIG_IR_LIRC_CODEC=m
CONFIG_IR_ENE=m
CONFIG_IR_IMON=m
CONFIG_IR_MCEUSB=m
CONFIG_IR_NUVOTON=m
CONFIG_IR_STREAMZAP=m
# CONFIG_IR_WINBOND_CIR is not set
# CONFIG_RC_LOOPBACK is not set
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=m
CONFIG_MEDIA_TUNER_CUSTOMISE=y

#
# Customize TV tuners
#
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA827X=m
CONFIG_MEDIA_TUNER_TDA18271=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_MT2060=m
CONFIG_MEDIA_TUNER_MT2266=m
CONFIG_MEDIA_TUNER_MT2131=m
CONFIG_MEDIA_TUNER_QT1010=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_MXL5005S=m
CONFIG_MEDIA_TUNER_MXL5007T=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_MEDIA_TUNER_MAX2165=m
CONFIG_MEDIA_TUNER_TDA18218=m
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEOBUF_DVB=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_IR_I2C=m

#
# Audio decoders
#
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_TDA9840=m
CONFIG_VIDEO_TEA6415C=m
CONFIG_VIDEO_TEA6420=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_CS5345=m
CONFIG_VIDEO_CS53L32A=m
CONFIG_VIDEO_M52790=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_WM8739=m
CONFIG_VIDEO_VP27SMPX=m

#
# RDS decoders
#
CONFIG_VIDEO_SAA6588=m

#
# Video decoders
#
CONFIG_VIDEO_BT819=m
CONFIG_VIDEO_BT856=m
CONFIG_VIDEO_BT866=m
CONFIG_VIDEO_KS0127=m
CONFIG_VIDEO_MT9V011=m
CONFIG_VIDEO_SAA7110=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_SAA717X=m
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VPX3220=m

#
# Video and audio decoders
#
CONFIG_VIDEO_CX25840=m

#
# MPEG video encoders
#
CONFIG_VIDEO_CX2341X=m

#
# Video encoders
#
CONFIG_VIDEO_SAA7127=m
CONFIG_VIDEO_SAA7185=m
CONFIG_VIDEO_ADV7170=m
CONFIG_VIDEO_ADV7175=m

#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=m
CONFIG_VIDEO_UPD64083=m
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_BT848_DVB=y
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA2=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_ZR36060=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_ZORAN_AVS6EYES=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_RC=y
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
# CONFIG_VIDEO_TIMBERDALE is not set
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_MPEG=m
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CX23885=m
CONFIG_VIDEO_AU0828=m
CONFIG_VIDEO_IVTV=m
CONFIG_VIDEO_FB_IVTV=m
CONFIG_VIDEO_CX18=m
CONFIG_VIDEO_CX18_ALSA=m
CONFIG_VIDEO_SAA7164=m
# CONFIG_VIDEO_CAFE_CCIC is not set
# CONFIG_VIDEO_SR030PC30 is not set
# CONFIG_VIDEO_VIA_CAMERA is not set
CONFIG_SOC_CAMERA=m
# CONFIG_SOC_CAMERA_IMX074 is not set
CONFIG_SOC_CAMERA_MT9M001=m
CONFIG_SOC_CAMERA_MT9M111=m
CONFIG_SOC_CAMERA_MT9T031=m
CONFIG_SOC_CAMERA_MT9T112=m
CONFIG_SOC_CAMERA_MT9V022=m
CONFIG_SOC_CAMERA_RJ54N1=m
CONFIG_SOC_CAMERA_TW9910=m
CONFIG_SOC_CAMERA_PLATFORM=m
# CONFIG_SOC_CAMERA_OV2640 is not set
# CONFIG_SOC_CAMERA_OV6650 is not set
CONFIG_SOC_CAMERA_OV772X=m
CONFIG_SOC_CAMERA_OV9640=m
CONFIG_V4L_USB_DRIVERS=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_GSPCA=m
CONFIG_USB_M5602=m
CONFIG_USB_STV06XX=m
CONFIG_USB_GL860=m
CONFIG_USB_GSPCA_BENQ=m
CONFIG_USB_GSPCA_CONEX=m
CONFIG_USB_GSPCA_CPIA1=m
CONFIG_USB_GSPCA_ETOMS=m
CONFIG_USB_GSPCA_FINEPIX=m
CONFIG_USB_GSPCA_JEILINJ=m
# CONFIG_USB_GSPCA_KONICA is not set
CONFIG_USB_GSPCA_MARS=m
CONFIG_USB_GSPCA_MR97310A=m
CONFIG_USB_GSPCA_OV519=m
CONFIG_USB_GSPCA_OV534=m
CONFIG_USB_GSPCA_OV534_9=m
CONFIG_USB_GSPCA_PAC207=m
CONFIG_USB_GSPCA_PAC7302=m
CONFIG_USB_GSPCA_PAC7311=m
CONFIG_USB_GSPCA_SN9C2028=m
CONFIG_USB_GSPCA_SN9C20X=m
CONFIG_USB_GSPCA_SONIXB=m
CONFIG_USB_GSPCA_SONIXJ=m
CONFIG_USB_GSPCA_SPCA500=m
CONFIG_USB_GSPCA_SPCA501=m
CONFIG_USB_GSPCA_SPCA505=m
CONFIG_USB_GSPCA_SPCA506=m
CONFIG_USB_GSPCA_SPCA508=m
CONFIG_USB_GSPCA_SPCA561=m
# CONFIG_USB_GSPCA_SPCA1528 is not set
CONFIG_USB_GSPCA_SQ905=m
CONFIG_USB_GSPCA_SQ905C=m
# CONFIG_USB_GSPCA_SQ930X is not set
CONFIG_USB_GSPCA_STK014=m
CONFIG_USB_GSPCA_STV0680=m
CONFIG_USB_GSPCA_SUNPLUS=m
CONFIG_USB_GSPCA_T613=m
CONFIG_USB_GSPCA_TV8532=m
CONFIG_USB_GSPCA_VC032X=m
# CONFIG_USB_GSPCA_XIRLINK_CIT is not set
CONFIG_USB_GSPCA_ZC3XX=m
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DVB=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_HDPVR=m
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=m
CONFIG_VIDEO_TLG2300=m
CONFIG_VIDEO_CX231XX=m
CONFIG_VIDEO_CX231XX_RC=y
CONFIG_VIDEO_CX231XX_ALSA=m
CONFIG_VIDEO_CX231XX_DVB=m
CONFIG_VIDEO_USBVISION=m
# CONFIG_USB_ET61X251 is not set
# CONFIG_USB_SN9C102 is not set
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
CONFIG_USB_PWC_INPUT_EVDEV=y
CONFIG_USB_ZR364XX=m
CONFIG_USB_STKWEBCAM=m
CONFIG_USB_S2255=m
CONFIG_V4L_MEM2MEM_DRIVERS=y
# CONFIG_VIDEO_MEM2MEM_TESTDEV is not set
CONFIG_RADIO_ADAPTERS=y
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_I2C_SI4713=m
CONFIG_RADIO_SI4713=m
CONFIG_USB_DSBR=m
CONFIG_RADIO_SI470X=y
CONFIG_USB_SI470X=m
CONFIG_I2C_SI470X=m
CONFIG_USB_MR800=m
# CONFIG_RADIO_TEA5764 is not set
# CONFIG_RADIO_SAA7706H is not set
# CONFIG_RADIO_TEF6862 is not set
# CONFIG_RADIO_WL1273 is not set
CONFIG_DVB_MAX_ADAPTERS=8
CONFIG_DVB_DYNAMIC_MINORS=y
CONFIG_DVB_CAPTURE_DRIVERS=y

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET_CORE=m
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m

#
# Supported USB Adapters
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_M920X=m
CONFIG_DVB_USB_GL861=m
CONFIG_DVB_USB_AU6610=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_USB_OPERA1=m
CONFIG_DVB_USB_AF9005=m
CONFIG_DVB_USB_AF9005_REMOTE=m
CONFIG_DVB_USB_DW2102=m
CONFIG_DVB_USB_CINERGY_T2=m
CONFIG_DVB_USB_ANYSEE=m
CONFIG_DVB_USB_DTV5100=m
CONFIG_DVB_USB_AF9015=m
CONFIG_DVB_USB_CE6230=m
CONFIG_DVB_USB_FRIIO=m
CONFIG_DVB_USB_EC168=m
CONFIG_DVB_USB_AZ6027=m
# CONFIG_DVB_USB_LME2510 is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_SMS_SIANO_MDTV=m

#
# Siano module components
#
CONFIG_SMS_USB_DRV=m
CONFIG_SMS_SDIO_DRV=m

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# Supported Pluto2 Adapters
#
CONFIG_DVB_PLUTO2=m

#
# Supported SDMC DM1105 Adapters
#
CONFIG_DVB_DM1105=m

#
# Supported Earthsoft PT1 Adapters
#
CONFIG_DVB_PT1=m

#
# Supported Mantis Adapters
#
CONFIG_MANTIS_CORE=m
CONFIG_DVB_MANTIS=m
CONFIG_DVB_HOPPER=m

#
# Supported nGene Adapters
#
CONFIG_DVB_NGENE=m

#
# Supported DVB Frontends
#
CONFIG_DVB_FE_CUSTOMISE=y

#
# Customise DVB Frontends
#

#
# Multistandard (satellite) frontends
#
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_STV090x=m
CONFIG_DVB_STV6110x=m

#
# DVB-S (satellite) frontends
#
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_MT312=m
CONFIG_DVB_ZL10036=m
CONFIG_DVB_ZL10039=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_STV0288=m
CONFIG_DVB_STB6000=m
CONFIG_DVB_STV0299=m
CONFIG_DVB_STV6110=m
CONFIG_DVB_STV0900=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
CONFIG_DVB_CX24116=m
CONFIG_DVB_SI21XX=m
CONFIG_DVB_DS3000=m
CONFIG_DVB_MB86A16=m

#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_S5H1432=m
CONFIG_DVB_DRX397XD=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_AF9013=m
CONFIG_DVB_EC100=m

#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_TDA10023=m
CONFIG_DVB_STV0297=m

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends #
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
CONFIG_DVB_LGDT3305=m
CONFIG_DVB_S5H1409=m
CONFIG_DVB_AU8522=m
CONFIG_DVB_S5H1411=m

#
# ISDB-T (terrestrial) frontends
#
CONFIG_DVB_S921=m
CONFIG_DVB_DIB8000=m
CONFIG_DVB_MB86A20S=m

#
# Digital terrestrial only tuners/PLL
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TUNER_DIB0070=m
CONFIG_DVB_TUNER_DIB0090=m

#
# SEC control devices for DVB-S
#
CONFIG_DVB_LNBP21=m
CONFIG_DVB_ISL6405=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_ISL6423=m
CONFIG_DVB_LGS8GL5=m
CONFIG_DVB_LGS8GXX=m
CONFIG_DVB_ATBM8830=m
CONFIG_DVB_TDA665x=m
CONFIG_DVB_IX2505V=m

#
# Tools to develop new frontends
#
CONFIG_DVB_DUMMY_FE=m

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_TTM=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_KMS=y
CONFIG_DRM_I810=m
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
# CONFIG_STUB_POULSBO is not set
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_SVGALIB=m
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=m
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
# CONFIG_FB_NVIDIA_DEBUG is not set
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA=m
# CONFIG_FB_RIVA_I2C is not set
# CONFIG_FB_RIVA_DEBUG is not set
CONFIG_FB_RIVA_BACKLIGHT=y
# CONFIG_FB_LE80578 is not set
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_BACKLIGHT=y
CONFIG_FB_S3=m
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
CONFIG_FB_VIA=m
# CONFIG_FB_VIA_DIRECT_PROCFS is not set
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_3DFX_ACCEL=y
CONFIG_FB_3DFX_I2C=y
CONFIG_FB_VOODOO1=m
# CONFIG_FB_VT8623 is not set
CONFIG_FB_TRIDENT=m
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_TMIO is not set
# CONFIG_FB_UDL is not set
CONFIG_FB_VIRTUAL=m
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_FB_METRONOME=m
CONFIG_FB_MB862XX=m
CONFIG_FB_MB862XX_PCI_GDC=y
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_LCD_PLATFORM=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PROGEAR=m
CONFIG_BACKLIGHT_MBP_NVIDIA=m
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_HRTIMER=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_VERBOSE is not set
CONFIG_SND_PCM_XRUN_DEBUG=y
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
CONFIG_SND_RAWMIDI_SEQ=m
CONFIG_SND_OPL3_LIB_SEQ=m
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
CONFIG_SND_EMU10K1_SEQ=m
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
# CONFIG_SND_ALOOP is not set
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_MTS64=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
CONFIG_SND_PORTMAN2X4=m
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_SB_COMMON=m
CONFIG_SND_SB16_DSP=m
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ASIHPI=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
# CONFIG_SND_AW2 is not set
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5530=m
CONFIG_SND_CS5535AUDIO=m
CONFIG_SND_CTXFI=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_INDIGOIOX=m
CONFIG_SND_INDIGODJX=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_ES1968_INPUT=y
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X_BOOL=y
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=0
CONFIG_SND_HDA_INPUT_JACK=y
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_LX6464ES=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MAESTRO3_INPUT=y
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
CONFIG_SND_RIPTIDE=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_UA101=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
CONFIG_SND_USB_US122L=m
CONFIG_SND_PCMCIA=y
CONFIG_SND_VXPOCKET=m
CONFIG_SND_PDAUDIOCF=m
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_3M_PCT=y
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACRUX_FF is not set
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CANDO=m
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_PRODIKEYS=m
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=m
CONFIG_DRAGONRISE_FF=y
# CONFIG_HID_EMS_FF is not set
CONFIG_HID_EGALAX=m
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
CONFIG_HID_GYRATION=m
CONFIG_HID_TWINHAN=m
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_LOGITECH_FF=y
CONFIG_LOGIRUMBLEPAD2_FF=y
CONFIG_LOGIG940_FF=y
# CONFIG_LOGIWII_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MOSART=y
CONFIG_HID_MONTEREY=y
# CONFIG_HID_MULTITOUCH is not set
CONFIG_HID_NTRIG=y
CONFIG_HID_ORTEK=m
CONFIG_HID_PANTHERLORD=m
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=m
CONFIG_HID_PICOLCD=m
CONFIG_HID_PICOLCD_FB=y
CONFIG_HID_PICOLCD_BACKLIGHT=y
CONFIG_HID_PICOLCD_LCD=y
CONFIG_HID_PICOLCD_LEDS=y
CONFIG_HID_QUANTA=y
CONFIG_HID_ROCCAT=m
CONFIG_HID_ROCCAT_KONE=m
# CONFIG_HID_ROCCAT_KONEPLUS is not set
# CONFIG_HID_ROCCAT_PYRA is not set
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
CONFIG_HID_STANTUM=y
CONFIG_HID_SUNPLUS=m
CONFIG_HID_GREENASIA=m
CONFIG_GREENASIA_FF=y
CONFIG_HID_SMARTJOYPLUS=m
CONFIG_SMARTJOYPLUS_FF=y
CONFIG_HID_TOPSEED=m
CONFIG_HID_THRUSTMASTER=m
CONFIG_THRUSTMASTER_FF=y
CONFIG_HID_ZEROPLUS=m
CONFIG_ZEROPLUS_FF=y
CONFIG_HID_ZYDACRON=m
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=y
CONFIG_USB_WUSB=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=m
# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_ISP1362_HCD=m
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_SL811_CS is not set
# CONFIG_USB_R8A66597_HCD is not set
CONFIG_USB_WHCI_HCD=m
CONFIG_USB_HWA_HCD=m

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may #

#

# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
# CONFIG_USB_UAS is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB port drivers
#
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=m
CONFIG_USB_EZUSB=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP210X=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7715_PARPORT=y
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_MOTOROLA=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
CONFIG_USB_SERIAL_QCAUX=m
CONFIG_USB_SERIAL_QUALCOMM=m
CONFIG_USB_SERIAL_SPCP8X5=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
# CONFIG_USB_SERIAL_SAMBA is not set
CONFIG_USB_SERIAL_SIEMENS_MPI=m
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_SYMBOL=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_WWAN=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_SERIAL_OPTICON=m
CONFIG_USB_SERIAL_VIVOPAY_SERIAL=m
# CONFIG_USB_SERIAL_ZIO is not set
# CONFIG_USB_SERIAL_SSU100 is not set
CONFIG_USB_SERIAL_DEBUG=m

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_SEVSEG=m
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
CONFIG_USB_TRANCEVIBRATOR=m
CONFIG_USB_IOWARRIOR=m
# CONFIG_USB_TEST is not set
CONFIG_USB_ISIGHTFW=m
# CONFIG_USB_YUREX is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
# CONFIG_USB_GPIO_VBUS is not set
CONFIG_NOP_USB_XCEIV=m
CONFIG_UWB=m
CONFIG_UWB_HWA=m
CONFIG_UWB_WHCI=m
CONFIG_UWB_I1480U=m
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=y
CONFIG_MMC_SDHCI_PLTFM=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m
CONFIG_MMC_SDRICOH_CS=m
CONFIG_MMC_CB710=m
CONFIG_MMC_VIA_SDMMC=m
# CONFIG_MMC_USHC is not set
CONFIG_MEMSTICK=y
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m

#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
CONFIG_MEMSTICK_JMICRON_38X=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_LT3593 is not set
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_GPIO is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set

#

# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_NFC_DEVICES is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1374=m
CONFIG_RTC_DRV_DS1672=m
# CONFIG_RTC_DRV_DS3232 is not set
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
# CONFIG_RTC_DRV_ISL12022 is not set
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_M41T80_WDT=y
CONFIG_RTC_DRV_BQ32K=m
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_RX8025=m

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1286=m
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_STK17TA8=m
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_M48T35=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_MSM6242=m
CONFIG_RTC_DRV_BQ4802=m
CONFIG_RTC_DRV_RP5C01=m
CONFIG_RTC_DRV_V3020=m

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
CONFIG_INTEL_MID_DMAC=m
CONFIG_INTEL_IOATDMA=m
# CONFIG_TIMB_DMA is not set
# CONFIG_PCH_DMA is not set
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set
CONFIG_DCA=m
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=m
# CONFIG_UIO_CIF is not set
# CONFIG_UIO_PDRV is not set
# CONFIG_UIO_PDRV_GENIRQ is not set
# CONFIG_UIO_AEC is not set
# CONFIG_UIO_SERCOS3 is not set
# CONFIG_UIO_PCI_GENERIC is not set
# CONFIG_UIO_NETX is not set

#
# Xen driver support
#
# CONFIG_XEN_BALLOON is not set
# CONFIG_XEN_DEV_EVTCHN is not set
CONFIG_XEN_BACKEND=y
# CONFIG_XENFS is not set
# CONFIG_XEN_SYS_HYPERVISOR is not set
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
# CONFIG_XEN_PLATFORM_PCI is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_STAGING=y
# CONFIG_STAGING_EXCLUDE_BUILD is not set
# CONFIG_ET131X is not set
# CONFIG_SLICOSS is not set
# CONFIG_VIDEO_GO7007 is not set
# CONFIG_VIDEO_CX25821 is not set
# CONFIG_VIDEO_TM6000 is not set
CONFIG_USB_DABUSB=m
CONFIG_USB_SE401=m
CONFIG_VIDEO_USBVIDEO=m
CONFIG_USB_VICAM=m
# CONFIG_USB_IP_COMMON is not set
# CONFIG_ECHO is not set
# CONFIG_COMEDI is not set
# CONFIG_ASUS_OLED is not set
# CONFIG_PANEL is not set
# CONFIG_TRANZPORT is not set
# CONFIG_POHMELFS is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_IDE_PHISON is not set
# CONFIG_LINE6_USB is not set
CONFIG_DRM_VMWGFX=m
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_NOUVEAU_DEBUG=y

#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
# CONFIG_USB_SERIAL_QUATECH2 is not set
# CONFIG_USB_SERIAL_QUATECH_USB2 is not set
# CONFIG_HYPERV is not set
# CONFIG_VME_BUS is not set
# CONFIG_DX_SEP is not set
# CONFIG_IIO is not set
# CONFIG_ZRAM is not set
# CONFIG_FB_SM7XX is not set
# CONFIG_VIDEO_DT3155 is not set
CONFIG_CRYSTALHD=m

#
# Texas Instruments shared transport line discipline #
# CONFIG_FB_XGI is not set CONFIG_LIRC_STAGING=y
CONFIG_LIRC_BT829=m CONFIG_LIRC_IGORPLUGUSB=m
CONFIG_LIRC_IMON=m
CONFIG_LIRC_IT87=m
CONFIG_LIRC_ITE8709=m
# CONFIG_LIRC_PARALLEL is not set CONFIG_LIRC_SASEM=m
CONFIG_LIRC_SERIAL=m CONFIG_LIRC_SERIAL_TRANSMITTER=y CONFIG_LIRC_SIR=m
CONFIG_LIRC_TTUSBIR=m
CONFIG_LIRC_ZILOG=m
# CONFIG_SMB_FS is not set
# CONFIG_EASYCAP is not set
# CONFIG_SOLO6X10 is not set
# CONFIG_ACPI_QUICKSTART is not set CONFIG_MACH_NO_WESTBRIDGE=y
# CONFIG_USB_ENESTORAGE is not set
# CONFIG_BCM_WIMAX is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_TOUCHSCREEN_CLEARPAD_TM1217 is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACERHDF is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set CONFIG_PANASONIC_LAPTOP=y
# CONFIG_THINKPAD_ACPI is not set CONFIG_SENSORS_HDAPS=m
# CONFIG_INTEL_MENLOW is not set
# CONFIG_EEEPC_LAPTOP is not set
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_TOSHIBA_BT_RFKILL is not set
# CONFIG_ACPI_CMPC is not set
# CONFIG_INTEL_IPS is not set
# CONFIG_IBM_RTL is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_EFI_VARS is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_FS_XIP=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_GENERIC_ACL=y

#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
CONFIG_FSCACHE_OBJECT_LIST=y
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=m
CONFIG_SQUASHFS=m
# CONFIG_SQUASHFS_XATTR is not set
# CONFIG_SQUASHFS_LZO is not set
# CONFIG_SQUASHFS_XZ is not set
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_EXOFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFS_USE_NEW_IDMAPPER is not set
CONFIG_NFSD=m
CONFIG_NFSD_DEPRECATED=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_DEBUG2=y
# CONFIG_CIFS_DFS_UPCALL is not set
# CONFIG_CIFS_FSCACHE is not set
# CONFIG_CIFS_ACL is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_STRIP_ASM_SYMS=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
CONFIG_DETECT_HUNG_TASK=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
CONFIG_SLUB_DEBUG_ON=y
# CONFIG_SLUB_STATS is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_BKL=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_PROVE_RCU=y
CONFIG_PROVE_RCU_REPEATEDLY=y
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_LKDTM=y
# CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FTRACE_NMI_ENTER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_RING_BUFFER=y
CONFIG_FTRACE_NMI_ENTER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENT=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
# CONFIG_EVENT_TRACE_TEST_SYSCALLS is not set
CONFIG_MMIOTRACE=y
# CONFIG_MMIOTRACE_TEST is not set
CONFIG_RING_BUFFER_BENCHMARK=m
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_BUILD_DOCSRC=y
CONFIG_DYNAMIC_DEBUG=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_ASYNC_RAID6_TEST=m
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_STRICT_DEVMEM=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_SET_MODULE_RONX is not set
CONFIG_DEBUG_NX_TEST=m
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_X86_DECODER_SELFTEST=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_TRUSTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_INTEL_TXT=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=m
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_X86_64=m
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=m

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_MMU_AUDIT=y
CONFIG_VHOST_NET=m
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_NLATTR=y

#41 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

In reply to Paul Turner
Quoted 135 lines · Paul Turner

From: Nikhil Rao <[email protected]>

This change introduces statistics exports for the cpu sub-system, these are added through the use of a stat file similar to that exported by other subsystems.

The following exports are included:

nr_periods: number of periods in which execution occurred
nr_throttled: the number of periods above in which execution was throttle
throttled_time: cumulative wall-time that any cpus have been throttled for
this group

---
 kernel/sched.c      |   26 ++++++++++++++++++++++++++
 kernel/sched_fair.c |   16 +++++++++++++++-
 2 files changed, 41 insertions(+), 1 deletion(-)

Index: tip/kernel/sched.c
===================================================================

kernel/sched.c +26 -0
@@ -254,6 +254,11 @@ struct cfs_bandwidth {
 	ktime_t			period;
 	u64			runtime, quota;
 	struct hrtimer		period_timer;
+
+	/* throttle statistics */
+	u64			nr_periods;
+	u64			nr_throttled;
+	u64			throttled_time;
 };
 #endif
 
@@ -389,6 +394,7 @@ struct cfs_rq {
 #ifdef CONFIG_CFS_BANDWIDTH
 	u64 quota_assigned, quota_used;
 	int throttled;
+	u64 throttled_timestamp;
 #endif
 #endif
 };
@@ -426,6 +432,10 @@ void init_cfs_bandwidth(struct cfs_bandw
 
 	hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	cfs_b->period_timer.function = sched_cfs_period_timer;
+
+	cfs_b->nr_periods = 0;
+	cfs_b->nr_throttled = 0;
+	cfs_b->throttled_time = 0;
 }
 
 static
@@ -9332,6 +9342,18 @@ static int cpu_cfs_period_write_u64(stru
 	return tg_set_cfs_period(cgroup_tg(cgrp), cfs_period_us);
 }
 
+static int cpu_stats_show(struct cgroup *cgrp, struct cftype *cft,
+		struct cgroup_map_cb *cb)
+{
+	struct task_group *tg = cgroup_tg(cgrp);
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);
+
+	cb->fill(cb, "nr_periods", cfs_b->nr_periods);
+	cb->fill(cb, "nr_throttled", cfs_b->nr_throttled);
+	cb->fill(cb, "throttled_time", cfs_b->throttled_time);
+
+	return 0;
+}
 #endif /* CONFIG_CFS_BANDWIDTH */
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
@@ -9378,6 +9400,10 @@ static struct cftype cpu_files[] = {
 		.read_u64 = cpu_cfs_period_read_u64,
 		.write_u64 = cpu_cfs_period_write_u64,
 	},
+	{
+		.name = "stat",
+		.read_map = cpu_stats_show,
+	},
 #endif
 #ifdef CONFIG_RT_GROUP_SCHED
 	{

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +10 -1
@@ -1519,17 +1519,25 @@ static void throttle_cfs_rq(struct cfs_r
 
 out_throttled:
 	cfs_rq->throttled = 1;
+	cfs_rq->throttled_timestamp = rq_of(cfs_rq)->clock;
 	update_cfs_rq_load_contribution(cfs_rq, 1);
 }
 
 static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
 {
 	struct rq *rq = rq_of(cfs_rq);
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
 	struct sched_entity *se;
 
 	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
 
 	update_rq_clock(rq);
+	/* update stats */
+	raw_spin_lock(&cfs_b->lock);
+	cfs_b->throttled_time += (rq->clock - cfs_rq->throttled_timestamp);
+	raw_spin_unlock(&cfs_b->lock);
+	cfs_rq->throttled_timestamp = 0;
+
 	/* (Try to) avoid maintaining share statistics for idle time */
 	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;
 
@@ -1571,7 +1579,7 @@ static void account_cfs_rq_quota(struct 
 
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
 {
-	int i, idle = 1;
+	int i, idle = 1, num_throttled = 0;
 	u64 delta;
 	const struct cpumask *span;
 
@@ -1593,6 +1601,7 @@ static int do_sched_cfs_period_timer(str
 
 		if (!cfs_rq_throttled(cfs_rq))
 			continue;
+		num_throttled++;
 
 		delta = tg_request_cfs_quota(cfs_rq->tg);
 
@@ -1608,6 +1617,11 @@ static int do_sched_cfs_period_timer(str
 		}

kernel/sched_fair.c static int do_sched_cfs_period_timer(str · line 1627

Quoted 10 lines
kernel/sched_fair.c +5 -0
 	}
 
+	/* update throttled stats */
+	cfs_b->nr_periods++;
+	if (num_throttled)
+		cfs_b->nr_throttled++;
+
 	return idle;
 }
 

Should we consider integrating this in cpuacct, it would be difficult if we spill over stats between controllers.

Signature · 2 lines
	Three Cheers,
	Balbir
Acked-by on v4 6/7
#50 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

In reply to Paul Turner

kernel/sched_fair.c static inline void update_entity_shares_ · line 940

Quoted 3 lines · Paul Turner
kernel/sched_fair.c +3 -0
+#ifdef CONFIG_CFS_BANDWIDTH
+/* maintain hierarchal task counts on group entities */
+static void account_hier_tasks(struct sched_entity *se, int delta)

I don't like the use of hier, I'd expand it to hierarchical

I am not too sure about the RT bits, but other than that

Signature · 2 lines
	Three Cheers,
	Balbir
#42 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

In reply to Balbir Singh
Quoted 139 lines · Balbir Singh
Quoted 137 lines · Paul Turner

From: Nikhil Rao <[email protected]>

This change introduces statistics exports for the cpu sub-system, these are added through the use of a stat file similar to that exported by other subsystems.

The following exports are included:

nr_periods: number of periods in which execution occurred
nr_throttled: the number of periods above in which execution was throttle
throttled_time: cumulative wall-time that any cpus have been throttled for
this group

---
 kernel/sched.c      |   26 ++++++++++++++++++++++++++
 kernel/sched_fair.c |   16 +++++++++++++++-
 2 files changed, 41 insertions(+), 1 deletion(-)

Index: tip/kernel/sched.c
===================================================================

kernel/sched.c +26 -0
@@ -254,6 +254,11 @@ struct cfs_bandwidth {
 	ktime_t			period;
 	u64			runtime, quota;
 	struct hrtimer		period_timer;
+
+	/* throttle statistics */
+	u64			nr_periods;
+	u64			nr_throttled;
+	u64			throttled_time;
 };
 #endif
 
@@ -389,6 +394,7 @@ struct cfs_rq {
 #ifdef CONFIG_CFS_BANDWIDTH
 	u64 quota_assigned, quota_used;
 	int throttled;
+	u64 throttled_timestamp;
 #endif
 #endif
 };
@@ -426,6 +432,10 @@ void init_cfs_bandwidth(struct cfs_bandw
 
 	hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	cfs_b->period_timer.function = sched_cfs_period_timer;
+
+	cfs_b->nr_periods = 0;
+	cfs_b->nr_throttled = 0;
+	cfs_b->throttled_time = 0;
 }
 
 static
@@ -9332,6 +9342,18 @@ static int cpu_cfs_period_write_u64(stru
 	return tg_set_cfs_period(cgroup_tg(cgrp), cfs_period_us);
 }
 
+static int cpu_stats_show(struct cgroup *cgrp, struct cftype *cft,
+		struct cgroup_map_cb *cb)
+{
+	struct task_group *tg = cgroup_tg(cgrp);
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);
+
+	cb->fill(cb, "nr_periods", cfs_b->nr_periods);
+	cb->fill(cb, "nr_throttled", cfs_b->nr_throttled);
+	cb->fill(cb, "throttled_time", cfs_b->throttled_time);
+
+	return 0;
+}
 #endif /* CONFIG_CFS_BANDWIDTH */
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
@@ -9378,6 +9400,10 @@ static struct cftype cpu_files[] = {
 		.read_u64 = cpu_cfs_period_read_u64,
 		.write_u64 = cpu_cfs_period_write_u64,
 	},
+	{
+		.name = "stat",
+		.read_map = cpu_stats_show,
+	},
 #endif
 #ifdef CONFIG_RT_GROUP_SCHED
 	{

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +10 -1
@@ -1519,17 +1519,25 @@ static void throttle_cfs_rq(struct cfs_r
 
 out_throttled:
 	cfs_rq->throttled = 1;
+	cfs_rq->throttled_timestamp = rq_of(cfs_rq)->clock;
 	update_cfs_rq_load_contribution(cfs_rq, 1);
 }
 
 static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
 {
 	struct rq *rq = rq_of(cfs_rq);
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
 	struct sched_entity *se;
 
 	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
 
 	update_rq_clock(rq);
+	/* update stats */
+	raw_spin_lock(&cfs_b->lock);
+	cfs_b->throttled_time += (rq->clock - cfs_rq->throttled_timestamp);
+	raw_spin_unlock(&cfs_b->lock);
+	cfs_rq->throttled_timestamp = 0;
+
 	/* (Try to) avoid maintaining share statistics for idle time */
 	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;
 
@@ -1571,7 +1579,7 @@ static void account_cfs_rq_quota(struct 
 
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
 {
-	int i, idle = 1;
+	int i, idle = 1, num_throttled = 0;
 	u64 delta;
 	const struct cpumask *span;
 
@@ -1593,6 +1601,7 @@ static int do_sched_cfs_period_timer(str
 
 		if (!cfs_rq_throttled(cfs_rq))
 			continue;
+		num_throttled++;
 
 		delta = tg_request_cfs_quota(cfs_rq->tg);
 
@@ -1608,6 +1617,11 @@ static int do_sched_cfs_period_timer(str
 		}
 	}
 
Quoted 11 lines

kernel/sched_fair.c static int do_sched_cfs_period_timer(str · line 1627

Quoted 8 lines
kernel/sched_fair.c +5 -0
+	/* update throttled stats */
+	cfs_b->nr_periods++;
+	if (num_throttled)
+		cfs_b->nr_throttled++;
+
 	return idle;
 }
 

Should we consider integrating this in cpuacct, it would be difficult if we spill over stats between controllers.

Given that cpuacct controller can be mounted independently, I am not sure if we should integrate these stats. These stats come from cpu controller.

I initially had similar stats as part of /proc/sched_debug since there are a bunch of other group specific stats (including rt throttle stats) in /proc/sched_debug.

Regards,
Bharata.

#43 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

Quoted 6 lines · Bharata B Rao
Quoted 3 lines

Should we consider integrating this in cpuacct, it would be difficult if we spill over stats between controllers.

Given that cpuacct controller can be mounted independently, I am not sure if we should integrate these stats. These stats come from cpu controller.

The accounting controller was created to account. I'd still prefer cpuacct, so that I can find everything in one place. NOTE: cpuacct was created so that we do accounting with control - just account. I think splitting stats creates a usability mess - no?

Signature · 2 lines
	Three Cheers,
	Balbir
#60 lore raw
In reply to Xiao Guangrong
Quoted 23 lines · Xiao Guangrong
Quoted 9 lines · Paul Turner

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Thanks for the great features!

I applied the patchset to kvm tree, then tested with kvm guest, unfortunately, it seems don't work normally.

The steps is follow:

# mount -t cgroup -o cpu none /mnt/
# qemu-system-x86_64 -enable-kvm  -smp 4 -m 512M -drive file=fc64.img,index=0,media=disk
Quoted 7 lines

Don't do any configuration in cgroup, and run the kvm guest directly (don't use libvirt), the guest booted very slowly and i saw some "soft lockup" bugs reported in the guest, i also noticed one CPU usage is 100% for more than 60s and other CPUs is 10%~30% in the host when guest was booting.

And if cgroup is not mounted, the guest runs well.

Hi Xiao Guangrong,

Thanks for testing the patches. I do see some soft lockups in the guest when I mount the cgroup and start VM using qemu-kvm.

Will get back after further investigation.

Regards,
Bharata.

#52 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

In reply to Paul Turner
Quoted 9 lines · Paul Turner
(quoted diff) +1 -0
@@ -1428,6 +1464,7 @@ enqueue_task_fair(struct rq *rq, struct 
 		update_cfs_shares(cfs_rq);
 	}
 
+	account_hier_tasks(&p->se, 1);
 	hrtick_update(rq);
 }
 

Review static void dequeue_task_fair(struct rq · line 1504

Quoted 7 lines
(quoted diff) +1 -0
@@ -1461,6 +1498,7 @@ static void dequeue_task_fair(struct rq 
 		update_cfs_shares(cfs_rq);
 	}
 
+	account_hier_tasks(&p->se, -1);
 	hrtick_update(rq);
 }
 

Why hrtick_update() is need to be delayed after modifying nr_running? You should not impact current hrtick logic without once mentioning.

Quoted 14 lines

Index: tip/kernel/sched_rt.c
===================================================================

kernel/sched_rt.c +2 -0
@@ -906,6 +906,8 @@ enqueue_task_rt(struct rq *rq, struct ta
 
 	if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
 		enqueue_pushable_task(rq, p);
+
+	inc_nr_running(rq);
 }
 
 static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)

kernel/sched_rt.c static void dequeue_task_rt(struct rq *r · line 925

Quoted 8 lines
kernel/sched_rt.c +2 -0
@@ -916,6 +918,8 @@ static void dequeue_task_rt(struct rq *r
 	dequeue_rt_entity(rt_se);
 
 	dequeue_pushable_task(rq, p);
+
+	dec_nr_running(rq);
 }
 
 /*

I think similar change for sched_stoptask.c is required.

In fact I could not boot tip/master with this v4 patchset. It reports rcu stall warns without applying following tweak:

kernel/sched_stoptask.c +2 -0
@@ -35,11 +35,13 @@ static struct task_struct *pick_next_task_stop(struct rq *rq
 static void
 enqueue_task_stop(struct rq *rq, struct task_struct *p, int flags)
 {
+       inc_nr_running(rq);
 }
 
 static void
 dequeue_task_stop(struct rq *rq, struct task_struct *p, int flags)
 {
+       dec_nr_running(rq);
 }
 
 

Thanks,
H.Seto

#53 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

Quoted 13 lines · Hidetoshi Seto
Quoted 12 lines · Paul Turner
(quoted diff) +1 -0
@@ -1428,6 +1464,7 @@ enqueue_task_fair(struct rq *rq, struct
               update_cfs_shares(cfs_rq);
       }
 
+     account_hier_tasks(&p->se, 1);
       hrtick_update(rq);
  }
 
@@ -1461,6 +1498,7 @@ static void dequeue_task_fair(struct rq
               update_cfs_shares(cfs_rq);
       }
 
Quoted 7 lines

Review static void dequeue_task_fair(struct rq · line 1504

Quoted 4 lines
(quoted diff) +1 -0
+     account_hier_tasks(&p->se, -1);
       hrtick_update(rq);
  }
 

Why hrtick_update() is need to be delayed after modifying nr_running? You should not impact current hrtick logic without once mentioning.

There shouldn't be any impact -- hrtick_update only cares about cfs_rq->nr_running which is independent of rq->nr_running (maintained by hierarchal accounting)

Quoted 17 lines
Quoted 17 lines

Index: tip/kernel/sched_rt.c
===================================================================

kernel/sched_rt.c +2 -0
@@ -906,6 +906,8 @@ enqueue_task_rt(struct rq *rq, struct ta
 
       if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
               enqueue_pushable_task(rq, p);
+
+     inc_nr_running(rq);
  }
 
  static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
@@ -916,6 +918,8 @@ static void dequeue_task_rt(struct rq *r
       dequeue_rt_entity(rt_se);
 
Quoted 8 lines

kernel/sched_rt.c static void dequeue_task_rt(struct rq *r · line 925

Quoted 6 lines
kernel/sched_rt.c +2 -0
       dequeue_pushable_task(rq, p);
+
+     dec_nr_running(rq);
  }
 
  /*

I think similar change for sched_stoptask.c is required.

Aha!

Yes, I missed this addition when re-basing.

It is needed since when something is placed into the stop-class via set_sched it goes through an activate/deactivate.

Will add, thanks!

Quoted 24 lines

In fact I could not boot tip/master with this v4 patchset. It reports rcu stall warns without applying following tweak:

kernel/sched_stoptask.c +0 -0
@@ -35,11 +35,13 @@ static struct task_struct *pick_next_task_stop(struct rq *rq

 static void
 enqueue_task_stop(struct rq *rq, struct task_struct *p, int flags) {
+       inc_nr_running(rq);
 }

 static void
 dequeue_task_stop(struct rq *rq, struct task_struct *p, int flags) {
+       dec_nr_running(rq);
 }

Thanks,
H.Seto

Acked-by
#54 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

In reply to Hidetoshi Seto
Quoted 54 lines · Hidetoshi Seto
Quoted 9 lines · Paul Turner
(quoted diff) +1 -0
@@ -1428,6 +1464,7 @@ enqueue_task_fair(struct rq *rq, struct 
 		update_cfs_shares(cfs_rq);
 	}
 
+	account_hier_tasks(&p->se, 1);
 	hrtick_update(rq);
 }
 

Review static void dequeue_task_fair(struct rq · line 1504

Quoted 7 lines
(quoted diff) +1 -0
@@ -1461,6 +1498,7 @@ static void dequeue_task_fair(struct rq 
 		update_cfs_shares(cfs_rq);
 	}
 
+	account_hier_tasks(&p->se, -1);
 	hrtick_update(rq);
 }
 

Why hrtick_update() is need to be delayed after modifying nr_running? You should not impact current hrtick logic without once mentioning.

Quoted 14 lines

Index: tip/kernel/sched_rt.c
===================================================================

kernel/sched_rt.c +2 -0
@@ -906,6 +906,8 @@ enqueue_task_rt(struct rq *rq, struct ta
 
 	if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
 		enqueue_pushable_task(rq, p);
+
+	inc_nr_running(rq);
 }
 
 static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)

kernel/sched_rt.c static void dequeue_task_rt(struct rq *r · line 925

Quoted 8 lines
kernel/sched_rt.c +2 -0
@@ -916,6 +918,8 @@ static void dequeue_task_rt(struct rq *r
 	dequeue_rt_entity(rt_se);
 
 	dequeue_pushable_task(rq, p);
+
+	dec_nr_running(rq);
 }
 
 /*

I think similar change for sched_stoptask.c is required.

In fact I could not boot tip/master with this v4 patchset. It reports rcu stall warns without applying following tweak:

kernel/sched_stoptask.c +0 -0
@@ -35,11 +35,13 @@ static struct task_struct *pick_next_task_stop(struct rq *rq
 static void
 enqueue_task_stop(struct rq *rq, struct task_struct *p, int flags)

kernel/sched_stoptask.c static struct task_struct *pick_next_task_stop(struct rq *rq · line 46

Quoted 10 lines
kernel/sched_stoptask.c +2 -0
 {
+       inc_nr_running(rq);
 }
 
 static void
 dequeue_task_stop(struct rq *rq, struct task_struct *p, int flags)
 {
+       dec_nr_running(rq);
 }
 

Good catch!

Signature · 2 lines
	Three Cheers,
	Balbir
#61 lore raw
In reply to Xiao Guangrong

Thanks for the report Xiao -- I wasn't able to reproduce this yet with a simple guest, I will try a more modern image tomorrow.

One suspicion is that this might be connected with the missing runnable accounting in sched_stoptask.c.

Quoted 135 lines · Xiao Guangrong
Quoted 9 lines · Paul Turner

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Thanks for the great features!

I applied the patchset to kvm tree, then tested with kvm guest, unfortunately, it seems don't work normally.

The steps is follow:

# mount -t cgroup -o cpu none /mnt/
# qemu-system-x86_64 -enable-kvm  -smp 4 -m 512M -drive file=fc64.img,index=0,media=disk

Don't do any configuration in cgroup, and run the kvm guest directly (don't use libvirt), the guest booted very slowly and i saw some "soft lockup" bugs reported in the guest, i also noticed one CPU usage is 100% for more than 60s and other CPUs is 10%~30% in the host when guest was booting.

And if cgroup is not mounted, the guest runs well.

The kernel config file is attached and my system cpu info is:

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 30
model name      : Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
stepping        : 5
cpu MHz         : 1197.000
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 5584.73
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 30
model name      : Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
stepping        : 5
cpu MHz         : 1197.000
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips        : 5585.03
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 30
model name      : Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
stepping        : 5
cpu MHz         : 1197.000
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips        : 5585.03
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 30
model name      : Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
stepping        : 5
cpu MHz         : 1197.000
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 6
initial apicid  : 6
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips        : 5585.03
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

#62 lore raw
Quoted 6 lines · Paul Turner

Thanks for the report Xiao -- I wasn't able to reproduce this yet with a simple guest, I will try a more modern image tomorrow.

One suspicion is that this might be connected with the missing runnable accounting in sched_stoptask.c.

I can confirm that, my guests work fine after the changes posted this morning. I still see some lockdep errors, but none associated with the scheduler.

Signature · 2 lines
	Three Cheers,
	Balbir
#63 lore raw
Quoted 5 lines · Balbir Singh
Quoted 3 lines · Paul Turner

Thanks for the report Xiao -- I wasn't able to reproduce this yet with a simple guest, I will try a more modern image tomorrow.

Quoted 8 lines
Quoted 3 lines

One suspicion is that this might be connected with the missing runnable accounting in sched_stoptask.c.

I can confirm that, my guests work fine after the changes posted this morning. I still see some lockdep errors, but none associated with the scheduler.

Excellent!

Ok, if this is resolved I'll roll this up and repost tomorrow, thanks!

Quoted 4 lines

--
       Three Cheers,
       Balbir

#44 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

In reply to Balbir Singh
Quoted 6 lines · Balbir Singh
Quoted 4 lines · Bharata B Rao
Quoted 3 lines

Should we consider integrating this in cpuacct, it would be difficult if we spill over stats between controllers.

Quoted 8 lines
Quoted 2 lines

Given that cpuacct controller can be mounted independently, I am not sure if we should integrate these stats. These stats come from cpu controller.

The accounting controller was created to account. I'd still prefer cpuacct, so that I can find everything in one place. NOTE: cpuacct was created so that we do accounting with control - just account. I think splitting stats creates a usability mess - no?

One problem with rolling it into cpuacct is that some of the statistics have a 1:1 association with the hierarchy being throttled. For example, the number of periods in which throttling occurred or the count of elapsed periods.

If it were rolled into cpuacct the only meaningful export would be the total throttled time -- perhaps this is sufficient?

Quoted 4 lines

--
       Three Cheers,
       Balbir

#51 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

In reply to Balbir Singh
Quoted 8 lines · Balbir Singh

kernel/sched_fair.c static inline void update_entity_shares_ · line 940

Quoted 3 lines · Paul Turner
kernel/sched_fair.c +3 -0
+#ifdef CONFIG_CFS_BANDWIDTH
+/* maintain hierarchal task counts on group entities */
+static void account_hier_tasks(struct sched_entity *se, int delta)

I don't like the use of hier, I'd expand it to hierarchical

Sure

Quoted 10 lines

I am not too sure about the RT bits, but other than that

--
       Three Cheers,
       Balbir

#64 lore raw
In reply to Paul Turner
Quoted 11 lines · Paul Turner
Quoted 9 lines · Balbir Singh
Quoted 6 lines · Paul Turner

Thanks for the report Xiao -- I wasn't able to reproduce this yet with a simple guest, I will try a more modern image tomorrow.

One suspicion is that this might be connected with the missing runnable accounting in sched_stoptask.c.

Quoted 8 lines
Quoted 4 lines

I can confirm that, my guests work fine after the changes posted this morning. I still see some lockdep errors, but none associated with the scheduler.

Excellent!

Ok, if this is resolved I'll roll this up and repost tomorrow, thanks!

As I said in an earlier reply, I too saw the lockups in guests. However those lockups didn't occur consistently. After the sched_stoptask.c changes, I haven't seen any lockups till now.

BTW, the lockups looked like this for me:

...
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Loading /lib/kbd/keymaps/i386/qwerty/us.map

BUG: soft lockup - CPU#0 stuck for 61s! [init:1]
Modules linked in:

Pid: 1, comm: init Not tainted (2.6.27.24-170.2.68.fc10.i686 #1) KVM
EIP: 0060:[<c041b93e>] EFLAGS: 00000297 CPU: 0
EIP is at __ticket_spin_lock+0x13/0x19
EAX: c080ff00 EBX: 00000000 ECX: c05751ca EDX: 00008584
ESI: df92c904 EDI: dd700d80 EBP: df819e50 ESP: df819e50
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: 0805d3dc CR3: 1d706000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400

 [<c06ab6cc>] lock_kernel+0x1f/0x2d
 [<c05751dc>] tty_open+0x12/0x2aa
 [<c0494a8c>] ? exact_match+0x0/0x7
 [<c0494dc7>] chrdev_open+0x12b/0x142
 [<c049141e>] __dentry_open+0x10e/0x1fc
 [<c0491593>] nameidata_to_filp+0x1f/0x33
 [<c0494c9c>] ? chrdev_open+0x0/0x142
 [<c049b0b7>] do_filp_open+0x31c/0x611
 [<c0422602>] ? set_next_entity+0x8b/0xf7
 [<c041f81a>] ? need_resched+0x18/0x22
 [<c049123c>] do_sys_open+0x42/0xb7
 [<c04912f3>] sys_open+0x1e/0x26
 [<c0404c8a>] syscall_call+0x7/0xb
 =======================
BUG: soft lockup - CPU#3 stuck for 61s! [plymouthd:562]
Modules linked in:

Pid: 562, comm: plymouthd Not tainted (2.6.27.24-170.2.68.fc10.i686 #1) KVM
EIP: 0060:[<c041b93e>] EFLAGS: 00000293 CPU: 3
EIP is at __ticket_spin_lock+0x13/0x19
EAX: c080ff00 EBX: 00000000 ECX: df469198 EDX: 00008684
ESI: df469198 EDI: df424018 EBP: dd6b9dc0 ESP: dd6b9dc0
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 80050033 CR2: 0804e767 CR3: 1d6b7000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400

 [<c06ab6cc>] lock_kernel+0x1f/0x2d
 [<c04c827a>] proc_lookup_de+0x15/0xc0
 [<c04c8337>] proc_lookup+0x12/0x17
 [<c04c4934>] proc_root_lookup+0x11/0x2b
 [<c0498fe2>] do_lookup+0xae/0x11e
 [<c049a408>] __link_path_walk+0x57e/0x6b5
 [<c049a92b>] path_walk+0x4c/0x9b
 [<c049ab27>] do_path_lookup+0x12d/0x175
 [<c049abb4>] __path_lookup_intent_open+0x45/0x76
 [<c049abf5>] path_lookup_open+0x10/0x12
 [<c049ae3c>] do_filp_open+0xa1/0x611
 [<c04fadaa>] ? selinux_file_alloc_security+0x22/0x41
 [<c052048c>] ? trace_hardirqs_on_thunk+0xc/0x10
 [<c0404cd7>] ? restore_nocheck_notrace+0x0/0xe
 [<c049123c>] do_sys_open+0x42/0xb7
 [<c04912f3>] sys_open+0x1e/0x26
 [<c0404c8a>] syscall_call+0x7/0xb
 =======================
BUG: soft lockup - CPU#2 stuck for 63s! [setfont:559]
Modules linked in:

Pid: 559, comm: setfont Not tainted (2.6.27.24-170.2.68.fc10.i686 #1) KVM
EIP: 0060:[<c053a892>] EFLAGS: 00010283 CPU: 2
EIP is at vgacon_do_font_op+0x177/0x3ec
EAX: c095a1f8 EBX: df904000 ECX: 00000001 EDX: 00000043
ESI: 00000004 EDI: c095a1f4 EBP: dd743e0c ESP: dd743df0
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: 0826d000 CR3: 1d73c000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400

 [<c053abac>] vgacon_font_set+0x59/0x208
 [<c04427d8>] ? down+0x2b/0x2f
 [<c053ab53>] ? vgacon_font_set+0x0/0x208
 [<c057f659>] con_font_op+0x15c/0x378
 [<c041f81a>] ? need_resched+0x18/0x22
 [<c057a80f>] vt_ioctl+0x1338/0x14fd
 [<c04fa419>] ? inode_has_perm+0x5b/0x65
 [<c05794d7>] ? vt_ioctl+0x0/0x14fd
 [<c0574b88>] tty_ioctl+0x665/0x6cf
 [<c04fa689>] ? file_has_perm+0x7b/0x84
 [<c0574523>] ? tty_ioctl+0x0/0x6cf
 [<c049c74a>] vfs_ioctl+0x22/0x69
 [<c049c9cc>] do_vfs_ioctl+0x23b/0x247
 [<c04fa7ac>] ? selinux_file_ioctl+0x35/0x38
 [<c049ca18>] sys_ioctl+0x40/0x5c
 [<c0404c8a>] syscall_call+0x7/0xb
 =======================
BUG: soft lockup - CPU#1 stuck for 63s! [loadkeys:560]
Modules linked in:

Pid: 560, comm: loadkeys Not tainted (2.6.27.24-170.2.68.fc10.i686 #1) KVM
EIP: 0060:[<c06ab54e>] EFLAGS: 00000282 CPU: 1
EIP is at _spin_unlock_irqrestore+0x2d/0x38
EAX: 00000282 EBX: 00000282 ECX: dd5b7f80 EDX: 00000282
ESI: c096f740 EDI: c096f7fc EBP: c08a5f78 ESP: c08a5f74
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: 009f0210 CR3: 1d73b000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400

 [<c0593456>] serial8250_handle_port+0x220/0x230
 [<c059114e>] ? serial_in+0x5a/0x61
 [<c05934af>] serial8250_interrupt+0x49/0xc9
 [<c0465313>] handle_IRQ_event+0x2f/0x64
 [<c04662b5>] handle_edge_irq+0xb2/0xf4
 [<c0466203>] ? handle_edge_irq+0x0/0xf4
 [<c0406e6e>] do_IRQ+0xc7/0xfe
 [<c0405668>] common_interrupt+0x28/0x30
 [<c06ab54e>] ? _spin_unlock_irqrestore+0x2d/0x38
 [<c058ef7d>] uart_start+0x4e/0x53
 [<c058fa1e>] uart_write+0xce/0xd9
 [<c0575d88>] write_chan+0x1e5/0x2b0
 [<c0428218>] ? default_wake_function+0x0/0xd
 [<c05742c9>] tty_write+0x155/0x1d5
 [<c0575ba3>] ? write_chan+0x0/0x2b0
 [<c05743a9>] redirected_tty_write+0x60/0x6d
 [<c0574349>] ? redirected_tty_write+0x0/0x6d
 [<c04930d6>] vfs_write+0x84/0xdf
 [<c04931ca>] sys_write+0x3b/0x60
 [<c0404c8a>] syscall_call+0x7/0xb
 =======================

input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 Setting up hotplug.
Creating block device nodes.
Creating character device nodes.

#45 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

In reply to Paul Turner
Quoted 16 lines · Paul Turner
Quoted 6 lines · Balbir Singh
Quoted 4 lines · Bharata B Rao
Quoted 3 lines

Should we consider integrating this in cpuacct, it would be difficult if we spill over stats between controllers.

Quoted 8 lines
Quoted 2 lines

Given that cpuacct controller can be mounted independently, I am not sure if we should integrate these stats. These stats come from cpu controller.

The accounting controller was created to account. I'd still prefer cpuacct, so that I can find everything in one place. NOTE: cpuacct was created so that we do accounting with control - just account. I think splitting stats creates a usability mess - no?

Quoted 8 lines

One problem with rolling it into cpuacct is that some of the statistics have a 1:1 association with the hierarchy being throttled. For example, the number of periods in which throttling occurred or the count of elapsed periods.

If it were rolled into cpuacct the only meaningful export would be the total throttled time -- perhaps this is sufficient?

Good point, lets keep it as is. nr_throttled and nr_periods is also important (although it can be derived).

Signature · 2 lines
	Three Cheers,
	Balbir
#35 lore raw

Re: [CFS Bandwidth Control v4 4/7] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

In reply to Paul Turner

kernel/sched.c void set_curr_task(int cpu, struct task_ · line 8512

Quoted 4 lines · Paul Turner
kernel/sched.c +4 -0
+static inline const struct cpumask *sched_bw_period_mask(void)
+{
+       return cpu_rq(smp_processor_id())->rd->span;
+}

Some day I'm going to bite the bullet and merge part of cpusets into this controller and have Balbir take the node part into the memcg thing and then make (cpu||memcg) ^ cpuset

Feh.

#9 lore raw

Re: [CFS Bandwidth Control v4 2/7] sched: accumulate per-cfs_rq cpu usage

In reply to Paul Turner

kernel/sched_fair.c static void update_curr(struct cfs_rq *c · line 637

Quoted 8 lines · Paul Turner
kernel/sched_fair.c +3 -0
@@ -609,6 +631,9 @@ static void update_curr(struct cfs_rq *c
 		cpuacct_charge(curtask, delta_exec);
 		account_group_exec_runtime(curtask, delta_exec);
 	}
+#ifdef CONFIG_CFS_BANDWIDTH
+	account_cfs_rq_quota(cfs_rq, delta_exec);
+#endif
 }

Not too hard to make the #ifdef'ery go away I'd guess.

Quoted 8 lines
kernel/sched_fair.c +3 -0
 static inline void
@@ -1382,6 +1407,43 @@ static void dequeue_task_fair(struct rq 
 }
 
 #ifdef CONFIG_CFS_BANDWIDTH
+static u64 tg_request_cfs_quota(struct task_group *tg)
+{
+	struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1422

Quoted 10 lines
kernel/sched_fair.c +10 -0
+	u64 delta = 0;
+
+	if (cfs_b->runtime > 0 || cfs_b->quota == RUNTIME_INF) {
+		raw_spin_lock(&cfs_b->lock);
+		/*
+		 * it's possible a bandwidth update has changed the global
+		 * pool.
+		 */
+		if (cfs_b->quota == RUNTIME_INF)
+			delta = sched_cfs_bandwidth_slice();

Why do we bother at all when there's infinite time? Shouldn't the action that sets it to infinite also make cfs_rq->quota_assinged to to RUNTIME_INF, in which case the below check will make it all go away?

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1431

Quoted 9 lines
kernel/sched_fair.c +9 -0
+		else {
+			delta = min(cfs_b->runtime,
+					sched_cfs_bandwidth_slice());
+			cfs_b->runtime -= delta;
+		}
+		raw_spin_unlock(&cfs_b->lock);
+	}
+	return delta;
+}

Also, shouldn't this all try and steal time from other cpus when the global limit ran out? Suppose you have say 24 cpus, and you had a short burst where all 24 cpus had some runtime, so you distribute 240ms. But 23 of those cpus only ran for 0.5ms, leaving 23.5ms of unused time on 23 cpus while your one active cpu will then throttle.

I would much rather see all the accounting tight first and optimize later than start with leaky stuff and try and plug holes later.

Quoted 4 lines
kernel/sched_fair.c +4 -0
+
+static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
+		unsigned long delta_exec)
+{

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1445

Quoted 10 lines
kernel/sched_fair.c +10 -0
+	if (cfs_rq->quota_assigned == RUNTIME_INF)
+		return;
+
+	cfs_rq->quota_used += delta_exec;
+
+	if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+		return;
+
+	cfs_rq->quota_assigned += tg_request_cfs_quota(cfs_rq->tg);
+}

So why isn't this hierarchical?, also all this positive quota stuff looks weird, why not decrement and try to supplement when negative?

#14 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Paul Turner

kernel/sched_fair.c static inline struct cfs_bandwidth *tg_c · line 344

Quoted 11 lines · Paul Turner
kernel/sched_fair.c +11 -0
+static inline int cfs_rq_throttled(struct cfs_rq *cfs_rq)
+{
+	return cfs_rq->throttled;
+}
+
+/* it's possible to be 'on_rq' in a dequeued (e.g. throttled) hierarchy */
+static inline int entity_on_rq(struct sched_entity *se)
+{
+	for_each_sched_entity(se)
+		if (!se->on_rq)
+			return 0;

Please add block braces over multi line stmts even if not strictly needed.

Quoted 8 lines
kernel/sched_fair.c +3 -0
+
+	return 1;
+}
@@ -761,7 +788,11 @@ static void update_cfs_load(struct cfs_r
 	u64 now, delta;
 	unsigned long load = cfs_rq->load.weight;

kernel/sched_fair.c static void update_cfs_load(struct cfs_r · line 798

Quoted 10 lines
kernel/sched_fair.c +5 -1
 
-	if (cfs_rq->tg == &root_task_group)
+	/*
+	 * Don't maintain averages for the root task group, or while we are
+	 * throttled.
+	 */
+	if (cfs_rq->tg == &root_task_group || cfs_rq_throttled(cfs_rq))
 		return;
 
 	now = rq_of(cfs_rq)->clock_task;

Placing the return there avoids updating the timestamps, so once we get unthrottled we'll observe a very long period and skew the load avg?

Ideally we'd never call this on throttled groups to begin with and handle them like full dequeue/enqueue like things.

Quoted 17 lines
kernel/sched_fair.c +8 -0
@@ -1015,6 +1046,14 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
 	 * Update run-time statistics of the 'current'.
 	 */
 	update_curr(cfs_rq);
+
+
+#ifdef CONFIG_CFS_BANDWIDTH
+	if (!entity_is_task(se) && (cfs_rq_throttled(group_cfs_rq(se)) ||
+	     !group_cfs_rq(se)->nr_running))
+		return;
+#endif
+
 	update_cfs_load(cfs_rq, 0);
 	account_entity_enqueue(cfs_rq, se);
 	update_cfs_shares(cfs_rq);
@@ -1087,6 +1126,11 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
 	 */

kernel/sched_fair.c dequeue_entity(struct cfs_rq *cfs_rq, st · line 1136

Quoted 10 lines
kernel/sched_fair.c +5 -0
 	update_curr(cfs_rq);
 
+#ifdef CONFIG_CFS_BANDWIDTH
+	if (!entity_is_task(se) && cfs_rq_throttled(group_cfs_rq(se)))
+		return;
+#endif
+
 	update_stats_dequeue(cfs_rq, se);
 	if (flags & DEQUEUE_SLEEP) {
 #ifdef CONFIG_SCHEDSTATS

These make me very nervous, on enqueue you bail after adding min_vruntime to ->vruntime and calling update_curr(), but on dequeue you bail before subtracting min_vruntime from ->vruntime.

Quoted 14 lines
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct 
 			break;
 		cfs_rq = cfs_rq_of(se);
 		enqueue_entity(cfs_rq, se, flags);
+		/* don't continue to enqueue if our parent is throttled */
+		if (cfs_rq_throttled(cfs_rq))
+			break;
 		flags = ENQUEUE_WAKEUP;
 	}
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq 
 		cfs_rq = cfs_rq_of(se);
 		dequeue_entity(cfs_rq, se, flags);
 

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1447

Quoted 10 lines
kernel/sched_fair.c +5 -2
-		/* Don't dequeue parent if it has other entities besides us */
-		if (cfs_rq->load.weight)
+		/*
+		 * Don't dequeue parent if it has other entities besides us,
+		 * or if it is throttled
+		 */
+		if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
 			break;
 		flags |= DEQUEUE_SLEEP;
 	}

How could we even be running if our parent was throttled?

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1489

Quoted 11 lines
kernel/sched_fair.c +7 -0
@@ -1430,6 +1480,42 @@ static u64 tg_request_cfs_quota(struct t
 	return delta;
 }
 
+static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+	struct sched_entity *se;
+
+	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+	/* account load preceeding throttle */

My spell checker thinks that should be written as: preceding.

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 9 lines
kernel/sched_fair.c +9 -0
+	update_cfs_load(cfs_rq, 0);
+
+	/* prevent previous buddy nominations from re-picking this se */
+	clear_buddies(cfs_rq_of(se), se);
+
+	/*
+	 * It's possible for the current task to block and re-wake before task
+	 * switch, leading to a throttle within enqueue_task->update_curr()
+	 * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

Quoted 23 lines
kernel/sched_fair.c +19 -0
+	 * In this case, since we haven't actually done the enqueue yet, cut
+	 * out and allow enqueue_entity() to short-circuit
+	 */
+	if (!se->on_rq)
+		goto out_throttled;
+
+	for_each_sched_entity(se) {
+		struct cfs_rq *cfs_rq = cfs_rq_of(se);
+
+		dequeue_entity(cfs_rq, se, 1);
+		if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
+			break;
+	}
+
+out_throttled:
+	cfs_rq->throttled = 1;
+	update_cfs_rq_load_contribution(cfs_rq, 1);
+}
+
 static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
 		unsigned long delta_exec)
 {

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 7 lines
kernel/sched_fair.c +2 -1
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct 
 
 	cfs_rq->quota_used += delta_exec;
 
-	if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+	if (cfs_rq_throttled(cfs_rq) ||
+		cfs_rq->quota_used < cfs_rq->quota_assigned)
 		return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

Quoted 10 lines
kernel/sched_fair.c +5 -0
 	cfs_rq->quota_assigned += tg_request_cfs_quota(cfs_rq->tg);
+
+	if (cfs_rq->quota_used >= cfs_rq->quota_assigned) {
+		throttle_cfs_rq(cfs_rq);
+		resched_task(cfs_rq->rq->curr);
+	}
 }
 
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)

kernel/sched_fair.c static void check_preempt_wakeup(struct · line 2037

Quoted 5 lines
kernel/sched_fair.c +2 -0
@@ -1941,6 +2033,12 @@ static void check_preempt_wakeup(struct 
 	if (unlikely(se == pse))
 		return;
 
+#ifdef CONFIG_CFS_BANDWIDTH
+	/* avoid pre-emption check/buddy nomination for throttled tasks */

Somehow my spell checker doesn't like that hyphen.

kernel/sched_fair.c static void check_preempt_wakeup(struct · line 2040

Quoted 3 lines
kernel/sched_fair.c +3 -0
+	if (!entity_on_rq(pse))
+		return;
+#endif

Ideally that #ifdef'ery would go away too.

kernel/sched_fair.c static bool yield_to_task_fair(struct rq · line 2163

Quoted 11 lines
kernel/sched_fair.c +2 -1
 	if (sched_feat(NEXT_BUDDY) && scale && !(wake_flags & WF_FORK))
 		set_next_buddy(pse);
 
@@ -2060,7 +2158,8 @@ static bool yield_to_task_fair(struct rq
 {
 	struct sched_entity *se = &p->se;
 
-	if (!se->on_rq)
+	/* ensure entire hierarchy is on rq (e.g. running & not throttled) */
+	if (!entity_on_rq(se))
 		return false;

like here..

kernel/sched_fair.c static void update_shares(int cpu) · line 2383

Quoted 8 lines
kernel/sched_fair.c +2 -1
 	/* Tell the scheduler that we'd really like pse to run next. */
@@ -2280,7 +2379,8 @@ static void update_shares(int cpu)
 
 	rcu_read_lock();
 	for_each_leaf_cfs_rq(rq, cfs_rq)
-		update_shares_cpu(cfs_rq->tg, cpu);
+		if (!cfs_rq_throttled(cfs_rq))
+			update_shares_cpu(cfs_rq->tg, cpu);

This wants extra braces

Quoted 18 lines
kernel/sched_fair.c +3 -2
 	rcu_read_unlock();
 }
 
@@ -2304,9 +2404,10 @@ load_balance_fair(struct rq *this_rq, in
 		u64 rem_load, moved_load;
 
 		/*
-		 * empty group
+		 * empty group or throttled cfs_rq
 		 */
-		if (!busiest_cfs_rq->task_weight)
+		if (!busiest_cfs_rq->task_weight ||
+				cfs_rq_throttled(busiest_cfs_rq))
 			continue;
 
 		rem_load = (u64)rem_load_move * busiest_weight;
#55 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

In reply to Paul Turner

kernel/sched.c static const struct sched_class rt_sched · line 1852

Quoted 8 lines · Paul Turner
kernel/sched.c +4 -0
@@ -1846,6 +1846,11 @@ static const struct sched_class rt_sched
 
 #include "sched_stats.h"
 
+static void mod_nr_running(struct rq *rq, long delta)
+{
+	rq->nr_running += delta;
+}

I personally don't see much use in such trivial wrappers.. if you're going to rework all the nr_running stuff you might as well remove all of that.

Quoted 40 lines

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +25 -0
@@ -81,6 +81,8 @@ unsigned int normalized_sysctl_sched_wak
 
 const_debug unsigned int sysctl_sched_migration_cost = 500000UL;
 
+static void account_hier_tasks(struct sched_entity *se, int delta);
+
 /*
  * The exponential sliding  window over which load is averaged for shares
  * distribution.
@@ -933,6 +935,40 @@ static inline void update_entity_shares_
 }
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
+#ifdef CONFIG_CFS_BANDWIDTH
+/* maintain hierarchal task counts on group entities */
+static void account_hier_tasks(struct sched_entity *se, int delta)
+{
+	struct rq *rq = rq_of(cfs_rq_of(se));
+	struct cfs_rq *cfs_rq;
+
+	for_each_sched_entity(se) {
+		/* a throttled entity cannot affect its parent hierarchy */
+		if (group_cfs_rq(se) && cfs_rq_throttled(group_cfs_rq(se)))
+			break;
+
+		/* we affect our queuing entity */
+		cfs_rq = cfs_rq_of(se);
+		cfs_rq->h_nr_tasks += delta;
+	}
+
+	/* account for global nr_running delta to hierarchy change */
+	if (!se)
+		mod_nr_running(rq, delta);
+}
+#else
+/*

kernel/sched_fair.c static inline void update_entity_shares_ · line 970

Quoted 10 lines
kernel/sched_fair.c +10 -0
+ * In the absence of group throttling, all operations are guaranteed to be
+ * globally visible at the root rq level.
+ */
+static void account_hier_tasks(struct sched_entity *se, int delta)
+{
+	struct rq *rq = rq_of(cfs_rq_of(se));
+
+	mod_nr_running(rq, delta);
+}
+#endif

While Balbir suggested expanding the _hier_ thing, I'd suggest to simply drop it altogether, way too much typing ;-), but that is if you cannot get rid of the extra hierarchy iteration, see below.

Quoted 38 lines
kernel/sched_fair.c +6 -0
+
 static void enqueue_sleeper(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
 #ifdef CONFIG_SCHEDSTATS
@@ -1428,6 +1464,7 @@ enqueue_task_fair(struct rq *rq, struct 
 		update_cfs_shares(cfs_rq);
 	}
 
+	account_hier_tasks(&p->se, 1);
 	hrtick_update(rq);
 }
 
@@ -1461,6 +1498,7 @@ static void dequeue_task_fair(struct rq 
 		update_cfs_shares(cfs_rq);
 	}
 
+	account_hier_tasks(&p->se, -1);
 	hrtick_update(rq);
 }
 
@@ -1488,6 +1526,8 @@ static u64 tg_request_cfs_quota(struct t
 	return delta;
 }
 
+static void account_hier_tasks(struct sched_entity *se, int delta);
+
 static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
 {
 	struct sched_entity *se;
@@ -1507,6 +1547,7 @@ static void throttle_cfs_rq(struct cfs_r
 	if (!se->on_rq)
 		goto out_throttled;
 
+	account_hier_tasks(se, -cfs_rq->h_nr_tasks);
 	for_each_sched_entity(se) {
 		struct cfs_rq *cfs_rq = cfs_rq_of(se);
 

kernel/sched_fair.c static void unthrottle_cfs_rq(struct cfs · line 1588

Quoted 7 lines
kernel/sched_fair.c +1 -0
@@ -1541,6 +1582,7 @@ static void unthrottle_cfs_rq(struct cfs
 	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;
 
 	cfs_rq->throttled = 0;
+	account_hier_tasks(se, cfs_rq->h_nr_tasks);
 	for_each_sched_entity(se) {
 		if (se->on_rq)
 			break;

All call-sites are right next to a for_each_sched_entity() iteration, is there really no way to fold those loops?

Quoted 23 lines

Index: tip/kernel/sched_rt.c
===================================================================

kernel/sched_rt.c +4 -0
@@ -906,6 +906,8 @@ enqueue_task_rt(struct rq *rq, struct ta
 
 	if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
 		enqueue_pushable_task(rq, p);
+
+	inc_nr_running(rq);
 }
 
 static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
@@ -916,6 +918,8 @@ static void dequeue_task_rt(struct rq *r
 	dequeue_rt_entity(rt_se);
 
 	dequeue_pushable_task(rq, p);
+
+	dec_nr_running(rq);
 }
 
 /*

kernel/sched_rt.c static void print_rt_stats(struct seq_fi · line 1789

Quoted 3 lines
kernel/sched_rt.c +0 -0
@@ -1783,4 +1787,3 @@ static void print_rt_stats(struct seq_fi
 	rcu_read_unlock();
 }
 #endif /* CONFIG_SCHED_DEBUG */

You mentioned something about -rt having the same problem, yet you don't fix it.. tskkk :-)

#46 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

In reply to Paul Turner

kernel/sched_fair.c static void throttle_cfs_rq(struct cfs_r · line 1538

Quoted 3 lines · Paul Turner
kernel/sched_fair.c +3 -0
+       raw_spin_lock(&cfs_b->lock);
+       cfs_b->throttled_time += (rq->clock - cfs_rq->throttled_timestamp);
+       raw_spin_unlock(&cfs_b->lock); 

That seems to put the cost of things on the wrong side. Read is rare, update is frequent, and you made the frequent thing the most expensive one.

#4 lore raw

Re: [CFS Bandwidth Control v4 1/7] sched: introduce primitives to account for CFS bandwidth tracking

In reply to Paul Turner

kernel/sched.c struct cfs_rq; · line 258

Quoted 12 lines · Paul Turner
kernel/sched.c +8 -0
@@ -245,6 +248,15 @@ struct cfs_rq;
 
 static LIST_HEAD(task_groups);
 
+#ifdef CONFIG_CFS_BANDWIDTH
+struct cfs_bandwidth {
+	raw_spinlock_t		lock;
+	ktime_t			period;
+	u64			runtime, quota;
+	struct hrtimer		period_timer;
+};
+#endif

If you write that as:

struct cfs_bandwidth {

#ifdef CONFIG_CFS_BANDWIDTH
	...

#endif
};

kernel/sched.c struct task_group { · line 295

Quoted 12 lines
kernel/sched.c +4 -0
 /* task group related information */
 struct task_group {
 	struct cgroup_subsys_state css;
@@ -276,6 +288,10 @@ struct task_group {
 #ifdef CONFIG_SCHED_AUTOGROUP
 	struct autogroup *autogroup;
 #endif
+
+#ifdef CONFIG_CFS_BANDWIDTH
+	struct cfs_bandwidth cfs_bandwidth;
+#endif
 };

You can avoid the #ifdef'ery here

Quoted 56 lines
kernel/sched.c +53 -0
 /* task_group_lock serializes the addition/removal of task groups */
@@ -370,9 +386,76 @@ struct cfs_rq {
 
+#ifdef CONFIG_CFS_BANDWIDTH
+static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun);
+
+static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
+{
+	struct cfs_bandwidth *cfs_b =
+		container_of(timer, struct cfs_bandwidth, period_timer);
+	ktime_t now;
+	int overrun;
+	int idle = 0;
+
+	for (;;) {
+		now = hrtimer_cb_get_time(timer);
+		overrun = hrtimer_forward(timer, now, cfs_b->period);
+
+		if (!overrun)
+			break;
+
+		idle = do_sched_cfs_period_timer(cfs_b, overrun);
+	}
+
+	return idle ? HRTIMER_NORESTART : HRTIMER_RESTART;
+}
+
+static
+void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b, u64 quota, u64 period)
+{
+	raw_spin_lock_init(&cfs_b->lock);
+	cfs_b->quota = cfs_b->runtime = quota;
+	cfs_b->period = ns_to_ktime(period);
+
+	hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+	cfs_b->period_timer.function = sched_cfs_period_timer;
+}
+
+static
+void init_cfs_rq_quota(struct cfs_rq *cfs_rq)
+{
+	cfs_rq->quota_used = 0;
+	if (cfs_rq->tg->cfs_bandwidth.quota == RUNTIME_INF)
+		cfs_rq->quota_assigned = RUNTIME_INF;
+	else
+		cfs_rq->quota_assigned = 0;
+}
+
+static void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+	if (cfs_b->quota == RUNTIME_INF)
+		return;
+
+	if (hrtimer_active(&cfs_b->period_timer))
+		return;
+

kernel/sched.c struct cfs_rq { · line 449

Quoted 10 lines
kernel/sched.c +10 -0
+	raw_spin_lock(&cfs_b->lock);
+	start_bandwidth_timer(&cfs_b->period_timer, cfs_b->period);
+	raw_spin_unlock(&cfs_b->lock);
+}
+
+static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+	hrtimer_cancel(&cfs_b->period_timer);
+}
+#endif

and #else

stubs
#endif

kernel/sched.c static void init_tg_cfs_entry(struct tas · line 8126

Quoted 10 lines
kernel/sched.c +3 -0
 /* Real-Time classes' related field in a runqueue: */
 struct rt_rq {
 	struct rt_prio_array active;
@@ -8038,6 +8121,9 @@ static void init_tg_cfs_entry(struct tas
 	tg->cfs_rq[cpu] = cfs_rq;
 	init_cfs_rq(cfs_rq, rq);
 	cfs_rq->tg = tg;
+#ifdef CONFIG_CFS_BANDWIDTH
+	init_cfs_rq_quota(cfs_rq);
+#endif

also avoids #ifdef'ery here

kernel/sched.c void __init sched_init(void) · line 8265

Quoted 10 lines
kernel/sched.c +4 -0
 	tg->se[cpu] = se;
 	/* se could be NULL for root_task_group */
@@ -8173,6 +8259,10 @@ void __init sched_init(void)
 		 * We achieve this by letting root_task_group's tasks sit
 		 * directly in rq->cfs (i.e root_task_group->se[] = NULL).
 		 */
+#ifdef CONFIG_CFS_BANDWIDTH
+		init_cfs_bandwidth(&root_task_group.cfs_bandwidth,
+				RUNTIME_INF, sched_cfs_bandwidth_period);
+#endif

and here

kernel/sched.c static void free_fair_sched_group(struct · line 8510

Quoted 10 lines
kernel/sched.c +3 -0
 		init_tg_cfs_entry(&root_task_group, &rq->cfs, NULL, i, NULL);
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
@@ -8415,6 +8505,10 @@ static void free_fair_sched_group(struct
 {
 	int i;
 
+#ifdef CONFIG_CFS_BANDWIDTH
+	destroy_cfs_bandwidth(&tg->cfs_bandwidth);
+#endif

and here

kernel/sched.c int alloc_fair_sched_group(struct task_g · line 8542

Quoted 12 lines
kernel/sched.c +4 -1
 	for_each_possible_cpu(i) {
 		if (tg->cfs_rq)
 			kfree(tg->cfs_rq[i]);
@@ -8442,7 +8536,10 @@ int alloc_fair_sched_group(struct task_g
 		goto err;
 
 	tg->shares = NICE_0_LOAD;
-
+#ifdef CONFIG_CFS_BANDWIDTH
+	init_cfs_bandwidth(&tg->cfs_bandwidth, RUNTIME_INF,
+			sched_cfs_bandwidth_period);
+#endif

and here

Quoted 32 lines
kernel/sched.c +24 -0
 	for_each_possible_cpu(i) {
 		rq = cpu_rq(i);
 
@@ -9107,6 +9204,116 @@ static u64 cpu_shares_read_u64(struct cg
 
 	return (u64) tg->shares;
 }
+
+#ifdef CONFIG_CFS_BANDWIDTH
+static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
+{
+	int i;
+	static DEFINE_MUTEX(mutex);
+
+	if (tg == &root_task_group)
+		return -EINVAL;
+
+	if (!period)
+		return -EINVAL;
+
+	/*
+	 * Ensure we have at least one tick of bandwidth every period.  This is
+	 * to prevent reaching a state of large arrears when throttled via
+	 * entity_tick() resulting in prolonged exit starvation.
+	 */
+	if (NS_TO_JIFFIES(quota) < 1)
+		return -EINVAL;
+
+	mutex_lock(&mutex);
+	raw_spin_lock_irq(&tg->cfs_bandwidth.lock);
+	tg->cfs_bandwidth.period = ns_to_ktime(period);

kernel/sched.c static u64 cpu_shares_read_u64(struct cg · line 9240

Quoted 10 lines
kernel/sched.c +10 -0
+	tg->cfs_bandwidth.runtime = tg->cfs_bandwidth.quota = quota;
+	raw_spin_unlock_irq(&tg->cfs_bandwidth.lock);
+
+	for_each_possible_cpu(i) {
+		struct cfs_rq *cfs_rq = tg->cfs_rq[i];
+		struct rq *rq = rq_of(cfs_rq);
+
+		raw_spin_lock_irq(&rq->lock);
+		init_cfs_rq_quota(cfs_rq);
+		raw_spin_unlock_irq(&rq->lock);

Any particular reason you didn't mirror rt_rq->rt_runtime_lock?

Quoted 28 lines
kernel/sched.c +5 -0
+	}
+	mutex_unlock(&mutex);
+
+	return 0;
+}
 
 

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +9 -0
@@ -88,6 +88,15 @@ const_debug unsigned int sysctl_sched_mi
  */
 unsigned int __read_mostly sysctl_sched_shares_window = 10000000UL;
 
+
+#ifdef CONFIG_CFS_BANDWIDTH
+/*
+ * default period for cfs group bandwidth.
+ * default: 0.5s, units: nanoseconds
+ */
+static u64 sched_cfs_bandwidth_period = 500000000ULL;
+#endif
+
 static const struct sched_class fair_sched_class;
 
 /**************************************************************

kernel/sched_fair.c static void __enqueue_entity(struct cfs_ · line 412

Quoted 7 lines
kernel/sched_fair.c +3 -0
@@ -397,6 +406,9 @@ static void __enqueue_entity(struct cfs_
 
 	rb_link_node(&se->run_node, parent, link);
 	rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
+#ifdef CONFIG_CFS_BANDWIDTH
+	start_cfs_bandwidth(&cfs_rq->tg->cfs_bandwidth);
+#endif
 }

This really needs to life elsewhere, __*_entity() functions are for rb-tree muck.

Quoted 1 line
kernel/sched_fair.c +0 -0
 static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
#36 lore raw

Re: [CFS Bandwidth Control v4 4/7] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

In reply to Paul Turner

kernel/sched_fair.c out_throttled: · line 1532

Quoted 10 lines · Paul Turner
kernel/sched_fair.c +10 -0
+static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+	struct rq *rq = rq_of(cfs_rq);
+	struct sched_entity *se;
+
+	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+	update_rq_clock(rq);
+	/* (Try to) avoid maintaining share statistics for idle time */
+	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;

Ok, so here you try to compensate for some of the weirdness from the previous patch.. wouldn't it be much saner to fully consider the throttled things dequeued for the load calculation etc.?

kernel/sched_fair.c out_throttled: · line 1542

Quoted 10 lines
kernel/sched_fair.c +10 -0
+
+	cfs_rq->throttled = 0;
+	for_each_sched_entity(se) {
+		if (se->on_rq)
+			break;
+
+		cfs_rq = cfs_rq_of(se);
+		enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
+		if (cfs_rq_throttled(cfs_rq))
+			break;

That's just weird, it was throttled, you enqueued it but find it throttled.

kernel/sched_fair.c out_throttled: · line 1545

Quoted 3 lines
kernel/sched_fair.c +3 -0
+	}
+
+	/* determine whether we need to wake up potentally idle cpu */

SP: potentially, also isn't there a determiner missing?

Quoted 12 lines
kernel/sched_fair.c +4 -1
+	if (rq->curr == rq->idle && rq->cfs.nr_running)
+		resched_task(rq->curr);
+}
+
 static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
 		unsigned long delta_exec)
 {
@@ -1535,8 +1569,46 @@ static void account_cfs_rq_quota(struct 
 
 static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
 {
-	return 1;

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1581

Quoted 10 lines
kernel/sched_fair.c +10 -0
+	int i, idle = 1;
+	u64 delta;
+	const struct cpumask *span;
+
+	if (cfs_b->quota == RUNTIME_INF)
+		return 1;
+
+	/* reset group quota */
+	raw_spin_lock(&cfs_b->lock);
+	cfs_b->runtime = cfs_b->quota;

Shouldn't that be something like:

cfs_b->runtime =
min(cfs_b->runtime + overrun * cfs_b->quota, cfs_b->quota);

afaict runtime can go negative in which case we need to compensate for that, but we cannot ever get more than quota because we allow for overcommit, so not limiting things would allow us to accrue an unlimited amount of runtime.

Or can only the per-cpu quota muck go negative? In that case it should probably be propagated back into the global bw on throttle, otherwise you can get deficits on CPUs that remain unused for a while.

Quoted 10 lines
kernel/sched_fair.c +10 -0
+	raw_spin_unlock(&cfs_b->lock);
+
+	span = sched_bw_period_mask();
+	for_each_cpu(i, span) {
+		struct rq *rq = cpu_rq(i);
+		struct cfs_rq *cfs_rq = cfs_bandwidth_cfs_rq(cfs_b, i);
+
+		if (cfs_rq->nr_running)
+			idle = 0;
+

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1601

Quoted 10 lines
kernel/sched_fair.c +10 -0
+		if (!cfs_rq_throttled(cfs_rq))
+			continue;
+
+		delta = tg_request_cfs_quota(cfs_rq->tg);
+
+		if (delta) {
+			raw_spin_lock(&rq->lock);
+			cfs_rq->quota_assigned += delta;
+
+			/* avoid race with tg_set_cfs_bandwidth */

*what* race, and *how*

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1610

Quoted 9 lines
kernel/sched_fair.c +8 -0
+			if (cfs_rq_throttled(cfs_rq) &&
+			     cfs_rq->quota_used < cfs_rq->quota_assigned)
+				unthrottle_cfs_rq(cfs_rq);
+			raw_spin_unlock(&rq->lock);
+		}
+	}
+
+	return idle;
 }

This whole positive quota muck makes my head hurt, whatever did you do that for? Also it doesn't deal with wrapping, which admittedly won't really happen but still.

#15 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Peter Zijlstra

Hi Peter,

I will only answer a couple of your questions and let Paul clarify the rest...

Quoted 17 lines · Peter Zijlstra
Quoted 14 lines · Paul Turner
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct 
 			break;
 		cfs_rq = cfs_rq_of(se);
 		enqueue_entity(cfs_rq, se, flags);
+		/* don't continue to enqueue if our parent is throttled */
+		if (cfs_rq_throttled(cfs_rq))
+			break;
 		flags = ENQUEUE_WAKEUP;
 	}
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq 
 		cfs_rq = cfs_rq_of(se);
 		dequeue_entity(cfs_rq, se, flags);
 
Quoted 12 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1447

Quoted 10 lines
kernel/sched_fair.c +5 -2
-		/* Don't dequeue parent if it has other entities besides us */
-		if (cfs_rq->load.weight)
+		/*
+		 * Don't dequeue parent if it has other entities besides us,
+		 * or if it is throttled
+		 */
+		if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
 			break;
 		flags |= DEQUEUE_SLEEP;
 	}

How could we even be running if our parent was throttled?

The task isn't running actually. One of its parents up in the heirarchy has been throttled and been already dequeued. Now this task sits on its immediate parent's runqueue which isn't throttled but not really running also since the hierarchy is throttled. In this situation, load balancer can try to pull this task. When that happens, load balancer tries to dequeue it and this check will ensure that we don't attempt to dequeue a group entity in our hierarchy which has already been dequeued.

Quoted 11 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 8 lines
kernel/sched_fair.c +2 -1
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct 
 
 	cfs_rq->quota_used += delta_exec;
 
-	if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+	if (cfs_rq_throttled(cfs_rq) ||
+		cfs_rq->quota_used < cfs_rq->quota_assigned)
 		return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

When a cfs_rq is throttled, its representative se (and all its parent se's) get dequeued and the task is marked for resched. But the task entity is still on its throttled parent's cfs_rq (=> task->se.on_rq = 1). Next during put_prev_task_fair(), we enqueue the task back on its throttled parent's cfs_rq at which time we end up calling update_curr() on throttled cfs_rq. This check would help us bail out from that situation.

Regards,
Bharata.

#37 lore raw

Re: [CFS Bandwidth Control v4 4/7] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

In reply to Peter Zijlstra
Quoted 17 lines · Peter Zijlstra

kernel/sched_fair.c out_throttled: · line 1532

Quoted 10 lines · Paul Turner
kernel/sched_fair.c +10 -0
+static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+	struct rq *rq = rq_of(cfs_rq);
+	struct sched_entity *se;
+
+	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+	update_rq_clock(rq);
+	/* (Try to) avoid maintaining share statistics for idle time */
+	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;

Ok, so here you try to compensate for some of the weirdness from the previous patch.. wouldn't it be much saner to fully consider the throttled things dequeued for the load calculation etc.?

Quoted 13 lines

kernel/sched_fair.c out_throttled: · line 1542

Quoted 10 lines
kernel/sched_fair.c +10 -0
+
+	cfs_rq->throttled = 0;
+	for_each_sched_entity(se) {
+		if (se->on_rq)
+			break;
+
+		cfs_rq = cfs_rq_of(se);
+		enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
+		if (cfs_rq_throttled(cfs_rq))
+			break;

That's just weird, it was throttled, you enqueued it but find it throttled.

se got enqueued to cfs_rq, but we find that cfs_rq is throttled and hence refrain from enqueueing cfs_rq futher.

So essentially enqueing to a throttled cfs_rq is allowed, but a throttled group entitiy can't be enqueued further.

Regards,
Bharata.

#16 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Bharata B Rao
Quoted 35 lines · Bharata B Rao

Hi Peter,

I will only answer a couple of your questions and let Paul clarify the rest...

Quoted 17 lines · Peter Zijlstra
Quoted 14 lines · Paul Turner
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct 
 			break;
 		cfs_rq = cfs_rq_of(se);
 		enqueue_entity(cfs_rq, se, flags);
+		/* don't continue to enqueue if our parent is throttled */
+		if (cfs_rq_throttled(cfs_rq))
+			break;
 		flags = ENQUEUE_WAKEUP;
 	}
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq 
 		cfs_rq = cfs_rq_of(se);
 		dequeue_entity(cfs_rq, se, flags);
 
Quoted 12 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1447

Quoted 10 lines
kernel/sched_fair.c +5 -2
-		/* Don't dequeue parent if it has other entities besides us */
-		if (cfs_rq->load.weight)
+		/*
+		 * Don't dequeue parent if it has other entities besides us,
+		 * or if it is throttled
+		 */
+		if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
 			break;
 		flags |= DEQUEUE_SLEEP;
 	}

How could we even be running if our parent was throttled?

Quoted 7 lines

The task isn't running actually. One of its parents up in the heirarchy has been throttled and been already dequeued. Now this task sits on its immediate parent's runqueue which isn't throttled but not really running also since the hierarchy is throttled. In this situation, load balancer can try to pull this task. When that happens, load balancer tries to dequeue it and this check will ensure that we don't attempt to dequeue a group entity in our hierarchy which has already been dequeued.

That's insane, its throttled, that means it should be dequeued and should thus invisible for the load-balancer. If it is visible the load-balancer will try and move tasks around to balance load, but all in vain, it'll move phantom loads around and get most confused at best.

Pure and utter suckage if you ask me.

Quoted 12 lines
Quoted 11 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 8 lines
kernel/sched_fair.c +2 -1
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct 
 
 	cfs_rq->quota_used += delta_exec;
 
-	if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+	if (cfs_rq_throttled(cfs_rq) ||
+		cfs_rq->quota_used < cfs_rq->quota_assigned)
 		return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

Quoted 6 lines

When a cfs_rq is throttled, its representative se (and all its parent se's) get dequeued and the task is marked for resched. But the task entity is still on its throttled parent's cfs_rq (=> task->se.on_rq = 1). Next during put_prev_task_fair(), we enqueue the task back on its throttled parent's cfs_rq at which time we end up calling update_curr() on throttled cfs_rq. This check would help us bail out from that situation.

But why bother with this early exit? At worst you'll call tg_request_cfs_quota() in vain, at best you'll find there is runtime because the period tick just happened on another cpu and you're good to go, yay!

#38 lore raw

Re: [CFS Bandwidth Control v4 4/7] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

In reply to Bharata B Rao
Quoted 32 lines · Bharata B Rao
Quoted 17 lines · Peter Zijlstra

kernel/sched_fair.c out_throttled: · line 1532

Quoted 10 lines · Paul Turner
kernel/sched_fair.c +10 -0
+static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+	struct rq *rq = rq_of(cfs_rq);
+	struct sched_entity *se;
+
+	se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+	update_rq_clock(rq);
+	/* (Try to) avoid maintaining share statistics for idle time */
+	cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;

Ok, so here you try to compensate for some of the weirdness from the previous patch.. wouldn't it be much saner to fully consider the throttled things dequeued for the load calculation etc.?

Quoted 13 lines

kernel/sched_fair.c out_throttled: · line 1542

Quoted 10 lines
kernel/sched_fair.c +10 -0
+
+	cfs_rq->throttled = 0;
+	for_each_sched_entity(se) {
+		if (se->on_rq)
+			break;
+
+		cfs_rq = cfs_rq_of(se);
+		enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
+		if (cfs_rq_throttled(cfs_rq))
+			break;

That's just weird, it was throttled, you enqueued it but find it throttled.

Quoted 5 lines

se got enqueued to cfs_rq, but we find that cfs_rq is throttled and hence refrain from enqueueing cfs_rq futher.

So essentially enqueing to a throttled cfs_rq is allowed, but a throttled group entitiy can't be enqueued further.

Argh, so this is about the total trainwreck you have for hierarchy semantics (which you've basically inherited from the RT bits I guess, which are similarly broken).

Do you want to support per-cgroup throttle periods? If so we need to sit down and work this out, if not the above should not be possible because each cgroup can basically run from the same refresh timer and everybody will get throttled at the same time.

#17 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Peter Zijlstra
Quoted 44 lines · Peter Zijlstra
Quoted 35 lines · Bharata B Rao

Hi Peter,

I will only answer a couple of your questions and let Paul clarify the rest...

Quoted 17 lines · Peter Zijlstra
Quoted 14 lines · Paul Turner
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct 
 			break;
 		cfs_rq = cfs_rq_of(se);
 		enqueue_entity(cfs_rq, se, flags);
+		/* don't continue to enqueue if our parent is throttled */
+		if (cfs_rq_throttled(cfs_rq))
+			break;
 		flags = ENQUEUE_WAKEUP;
 	}
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq 
 		cfs_rq = cfs_rq_of(se);
 		dequeue_entity(cfs_rq, se, flags);
 
Quoted 12 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1447

Quoted 10 lines
kernel/sched_fair.c +5 -2
-		/* Don't dequeue parent if it has other entities besides us */
-		if (cfs_rq->load.weight)
+		/*
+		 * Don't dequeue parent if it has other entities besides us,
+		 * or if it is throttled
+		 */
+		if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
 			break;
 		flags |= DEQUEUE_SLEEP;
 	}

How could we even be running if our parent was throttled?

Quoted 7 lines

The task isn't running actually. One of its parents up in the heirarchy has been throttled and been already dequeued. Now this task sits on its immediate parent's runqueue which isn't throttled but not really running also since the hierarchy is throttled. In this situation, load balancer can try to pull this task. When that happens, load balancer tries to dequeue it and this check will ensure that we don't attempt to dequeue a group entity in our hierarchy which has already been dequeued.

Quoted 4 lines

That's insane, its throttled, that means it should be dequeued and should thus invisible for the load-balancer. If it is visible the load-balancer will try and move tasks around to balance load, but all in vain, it'll move phantom loads around and get most confused at best.

We can't walk the se hierarchy downwards and hence can't really dequeue the entire hierarchy if any one entity in the hierarchy is throttled. However this semantics of retaining the child entities enqueued while dequeuing the entities upwards of a throttled entity makes our life simple during unthrottling. We just have to enqueue the entities upwards the throttled entity and the rest of the entities downwards automatically become available.

While I admit that our load balancing semantics wrt thorttled entities are not consistent (we don't allow pulling of tasks directly from throttled cfs_rqs, while allow pulling of tasks from a throttled hierarchy as in the above case), I am beginning to think if it works out to be advantageous. Is there a chance that the task gets to run on other CPU where the hierarchy isn't throttled since runtime is still available ?

Quoted 22 lines

Pure and utter suckage if you ask me.

Quoted 12 lines
Quoted 11 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 8 lines
kernel/sched_fair.c +2 -1
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct 
 
 	cfs_rq->quota_used += delta_exec;
 
-	if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+	if (cfs_rq_throttled(cfs_rq) ||
+		cfs_rq->quota_used < cfs_rq->quota_assigned)
 		return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

Quoted 6 lines

When a cfs_rq is throttled, its representative se (and all its parent se's) get dequeued and the task is marked for resched. But the task entity is still on its throttled parent's cfs_rq (=> task->se.on_rq = 1). Next during put_prev_task_fair(), we enqueue the task back on its throttled parent's cfs_rq at which time we end up calling update_curr() on throttled cfs_rq. This check would help us bail out from that situation.

Quoted 4 lines

But why bother with this early exit? At worst you'll call tg_request_cfs_quota() in vain, at best you'll find there is runtime because the period tick just happened on another cpu and you're good to go, yay!

I see your point. I had this check in my version of hard limits patches earlier for the reason I described above. Lets see if Paul had any other reason to retain this check.

Regards,
Bharata.

#18 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

Quoted 6 lines · Bharata B Rao

While I admit that our load balancing semantics wrt thorttled entities are not consistent (we don't allow pulling of tasks directly from throttled cfs_rqs, while allow pulling of tasks from a throttled hierarchy as in the above case), I am beginning to think if it works out to be advantageous. Is there a chance that the task gets to run on other CPU where the hierarchy isn't throttled since runtime is still available ?

Possible yes, but the load-balancer doesn't know about that, not should it (its complicated, and broken, enough, no need to add more cruft to it).

I'm starting to think you all should just toss all this and start over, its just too smelly.

#19 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

Quoted 8 lines · Peter Zijlstra
Quoted 6 lines · Bharata B Rao

While I admit that our load balancing semantics wrt thorttled entities are not consistent (we don't allow pulling of tasks directly from throttled cfs_rqs, while allow pulling of tasks from a throttled hierarchy as in the above case), I am beginning to think if it works out to be advantageous. Is there a chance that the task gets to run on other CPU where the hierarchy isn't throttled since runtime is still available ?

Quoted 6 lines

Possible yes, but the load-balancer doesn't know about that, not should it (its complicated, and broken, enough, no need to add more cruft to it).

I'm starting to think you all should just toss all this and start over, its just too smelly.

Hmm... You have brought up 3 concerns:

1. Hierarchy semantics

If you look at the heirarchy semantics we currently have while ignoring the load balancer interactions for a moment, I guess what we have is a reasonable one.

- Only group entities are throttled
- Throttled entities are taken off the runqueue and hence they never get picked up for scheduling.
- New or child entites are queued up to the throttled entities and not further up. As I said in another thread, having the tree intact and correct underneath the throttled entity allows us to rebuild the hierarchy during unthrottling with least amount of effort.
- Group entities in a hierarchy are throttled independent of each other based on their bandwidth specification.

2. Handling of throttled entities by load balancer

This definetely needs to improve and be more consistent. We can work on this.

3. per-cgroup vs global period specification

I thought per-cgroup specification would be most flexible and hence started out with that. This would allow groups/workloads/VMs to define their own bandwidth rate.

Let us know if you have other design concerns besides these.

Regards,
Bharata.

#20 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

Quoted 24 lines · Bharata B Rao
Quoted 8 lines · Peter Zijlstra
Quoted 6 lines · Bharata B Rao

While I admit that our load balancing semantics wrt thorttled entities are not consistent (we don't allow pulling of tasks directly from throttled cfs_rqs, while allow pulling of tasks from a throttled hierarchy as in the above case), I am beginning to think if it works out to be advantageous. Is there a chance that the task gets to run on other CPU where the hierarchy isn't throttled since runtime is still available ?

Quoted 6 lines

Possible yes, but the load-balancer doesn't know about that, not should it (its complicated, and broken, enough, no need to add more cruft to it).

I'm starting to think you all should just toss all this and start over, its just too smelly.

Hmm... You have brought up 3 concerns:

1. Hierarchy semantics

If you look at the heirarchy semantics we currently have while ignoring the load balancer interactions for a moment, I guess what we have is a reasonable one.

Quoted 7 lines

- Only group entities are throttled
- Throttled entities are taken off the runqueue and hence they never get picked up for scheduling.
- New or child entites are queued up to the throttled entities and not further up. As I said in another thread, having the tree intact and correct underneath the throttled entity allows us to rebuild the hierarchy during unthrottling with least amount of effort.

It also gets you into all that load-balancer mess, and I'm not going to let you off lightly there.

Quoted 2 lines

- Group entities in a hierarchy are throttled independent of each other based on their bandwidth specification.

That's missing out quite a few details.. for one there is no mention of hierarchical implication of/constraints on bandwidth, can children have more bandwidth than their parent (I hope not).

Quoted 3 lines

2. Handling of throttled entities by load balancer

This definetely needs to improve and be more consistent. We can work on this.

Feh, improve is being nice about it, it needs a complete overhaul, the current situation is a cobbled together leaky mess.

Quoted 5 lines

3. per-cgroup vs global period specification

I thought per-cgroup specification would be most flexible and hence started out with that. This would allow groups/workloads/VMs to define their own bandwidth rate.

Most flexible yes, most 'interesting' too, now if you consider running a child task is also running the parent entity and therefore you're consuming bandwidth up the entire hierarchy, what happens when the parent has a much larger period than the child?

In that case your child doesn't get ran while the parent is throttled, and the child's period is violated.

Quoted 1 line

Let us know if you have other design concerns besides these.

Yeah, that weird time accounting muck, bandwidth should decrease on usage and incremented on replenishment, this gets you 0 as the natural boundary between credit and debt, no need to keep two variables.

Also, the above just about covers all the patch set does, isn't that enough justification to throw the thing out and start over?

#23 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Peter Zijlstra
Quoted 17 lines · Peter Zijlstra

kernel/sched_fair.c static inline struct cfs_bandwidth *tg_c · line 344

Quoted 11 lines · Paul Turner
kernel/sched_fair.c +11 -0
+static inline int cfs_rq_throttled(struct cfs_rq *cfs_rq)
+{
+     return cfs_rq->throttled;
+}
+
+/* it's possible to be 'on_rq' in a dequeued (e.g. throttled) hierarchy */
+static inline int entity_on_rq(struct sched_entity *se)
+{
+     for_each_sched_entity(se)
+             if (!se->on_rq)
+                     return 0;

Please add block braces over multi line stmts even if not strictly needed.

Done

Quoted 17 lines
Quoted 17 lines
kernel/sched_fair.c +8 -1
+
+     return 1;
+}
@@ -761,7 +788,11 @@ static void update_cfs_load(struct cfs_r
       u64 now, delta;
       unsigned long load = cfs_rq->load.weight;
 
-     if (cfs_rq->tg == &root_task_group)
+     /*
+      * Don't maintain averages for the root task group, or while we are
+      * throttled.
+      */
+     if (cfs_rq->tg == &root_task_group || cfs_rq_throttled(cfs_rq))
               return;
 
Quoted 5 lines

kernel/sched_fair.c static void update_cfs_load(struct cfs_r · line 798

Quoted 1 line
kernel/sched_fair.c +0 -0
       now = rq_of(cfs_rq)->clock_task;

Placing the return there avoids updating the timestamps, so once we get unthrottled we'll observe a very long period and skew the load avg?

It's easier to avoid this by fixing up the load average on unthrottle, since there's no point in moving up the intermediate timestamps on each throttled update.

The one "gotcha" in either case is that it's possible for time to drift on the child of a throttled group and I don't see an easy way around this.

Quoted 3 lines

Ideally we'd never call this on throttled groups to begin with and handle them like full dequeue/enqueue like things.

This is what is attempted -- however it's still possible actions such as wakeup which may still occur against throttled groups regardless of their queue state.

In this case we still need to preserve the correct child hierarchy state so that it can be re-enqueued when there is again bandwidth.

Quoted 19 lines
Quoted 19 lines
kernel/sched_fair.c +8 -0
@@ -1015,6 +1046,14 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
        * Update run-time statistics of the 'current'.
        */
       update_curr(cfs_rq);
+
+
+#ifdef CONFIG_CFS_BANDWIDTH
+     if (!entity_is_task(se) && (cfs_rq_throttled(group_cfs_rq(se)) ||
+          !group_cfs_rq(se)->nr_running))
+             return;
+#endif
+
       update_cfs_load(cfs_rq, 0);
       account_entity_enqueue(cfs_rq, se);
       update_cfs_shares(cfs_rq);
@@ -1087,6 +1126,11 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
        */
       update_curr(cfs_rq);
 
Quoted 13 lines

kernel/sched_fair.c dequeue_entity(struct cfs_rq *cfs_rq, st · line 1136

Quoted 8 lines
kernel/sched_fair.c +5 -0
+#ifdef CONFIG_CFS_BANDWIDTH
+     if (!entity_is_task(se) && cfs_rq_throttled(group_cfs_rq(se)))
+             return;
+#endif
+
       update_stats_dequeue(cfs_rq, se);
       if (flags & DEQUEUE_SLEEP) {
  #ifdef CONFIG_SCHEDSTATS

These make me very nervous, on enqueue you bail after adding min_vruntime to ->vruntime and calling update_curr(), but on dequeue you bail before subtracting min_vruntime from ->vruntime.

min_vruntime shouldn't be added in enqueue since unthrottling is treated as a wakeup (which results in placement versus min as opposed to normalization).

Quoted 14 lines
Quoted 14 lines
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct
                       break;
               cfs_rq = cfs_rq_of(se);
               enqueue_entity(cfs_rq, se, flags);
+             /* don't continue to enqueue if our parent is throttled */
+             if (cfs_rq_throttled(cfs_rq))
+                     break;
               flags = ENQUEUE_WAKEUP;
       }
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq
               cfs_rq = cfs_rq_of(se);
               dequeue_entity(cfs_rq, se, flags);
 
Quoted 13 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1447

Quoted 10 lines
kernel/sched_fair.c +5 -2
-             /* Don't dequeue parent if it has other entities besides us */
-             if (cfs_rq->load.weight)
+             /*
+              * Don't dequeue parent if it has other entities besides us,
+              * or if it is throttled
+              */
+             if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
                       break;
               flags |= DEQUEUE_SLEEP;
       }

How could we even be running if our parent was throttled?

It's possible we throttled within the preceding dequeue_entity -- the partial update_curr against cfs_rq might be just enough to push it over the edge. In which case that entity has already been dequeued and we want to bail out.

Quoted 4 lines
Quoted 4 lines
kernel/sched_fair.c +0 -0
@@ -1430,6 +1480,42 @@ static u64 tg_request_cfs_quota(struct t
       return delta;
  }
 
Quoted 10 lines

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1489

Quoted 7 lines
kernel/sched_fair.c +7 -0
+static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+     struct sched_entity *se;
+
+     se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+     /* account load preceeding throttle */

My spell checker thinks that should be written as: preceding.

My fat fingers have corrected this typo.

Quoted 12 lines

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 9 lines
kernel/sched_fair.c +9 -0
+     update_cfs_load(cfs_rq, 0);
+
+     /* prevent previous buddy nominations from re-picking this se */
+     clear_buddies(cfs_rq_of(se), se);
+
+     /*
+      * It's possible for the current task to block and re-wake before task
+      * switch, leading to a throttle within enqueue_task->update_curr()
+      * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

I'm not sure the example Bharata gave is correct -- I'm going to treat that discussion separately as it's not the intent here.

Here the task _is_ running.

Specifically:

- Suppose the current task on a cfs_rq blocks
- Accordingly we issue dequeue against that task (however it remains as curr until the put)
- Before we get to the put some other activity (e.g. network bottom half) gets to run and re-wake the task
- The time elapsed for this is charged to the task, which might push it over its reservation, it then gets throttled while we're trying to queue it

BUT

We haven't actually done any of the enqueue work yet so there's nothing to do to take it off rq. So what we just mark it throttled and make sure that the rest of the enqueue work gets short circuited.

The clock_task helps reduce the occurrence of this since the task will be spared the majority of the SI time but it's still possible to push it over.

Quoted 26 lines
Quoted 26 lines
kernel/sched_fair.c +19 -0
+      * In this case, since we haven't actually done the enqueue yet, cut
+      * out and allow enqueue_entity() to short-circuit
+      */
+     if (!se->on_rq)
+             goto out_throttled;
+
+     for_each_sched_entity(se) {
+             struct cfs_rq *cfs_rq = cfs_rq_of(se);
+
+             dequeue_entity(cfs_rq, se, 1);
+             if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
+                     break;
+     }
+
+out_throttled:
+     cfs_rq->throttled = 1;
+     update_cfs_rq_load_contribution(cfs_rq, 1);
+}
+
  static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
               unsigned long delta_exec)
  {
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct
 
       cfs_rq->quota_used += delta_exec;
 
Quoted 8 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 4 lines
kernel/sched_fair.c +2 -1
-     if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+     if (cfs_rq_throttled(cfs_rq) ||
+             cfs_rq->quota_used < cfs_rq->quota_assigned)
               return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

No -- this is just the fact that there are cases where reschedule can't evict the task immediately.

e.g. softirq or any kernel time without config_preempt

Once we're throttled we know there's no time left or point in trying to acquire it so just short circuit these until we get to a point where this task can be removed from rq.

Quoted 13 lines
Quoted 13 lines
kernel/sched_fair.c +5 -0
       cfs_rq->quota_assigned += tg_request_cfs_quota(cfs_rq->tg);
+
+     if (cfs_rq->quota_used >= cfs_rq->quota_assigned) {
+             throttle_cfs_rq(cfs_rq);
+             resched_task(cfs_rq->rq->curr);
+     }
  }
 
  static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
@@ -1941,6 +2033,12 @@ static void check_preempt_wakeup(struct
       if (unlikely(se == pse))
               return;
 
Quoted 5 lines

kernel/sched_fair.c static void check_preempt_wakeup(struct · line 2037

Quoted 2 lines
kernel/sched_fair.c +2 -0
+#ifdef CONFIG_CFS_BANDWIDTH
+     /* avoid pre-emption check/buddy nomination for throttled tasks */

Somehow my spell checker doesn't like that hyphen.

Fixed

Quoted 5 lines

kernel/sched_fair.c static void check_preempt_wakeup(struct · line 2040

Quoted 3 lines
kernel/sched_fair.c +3 -0
+     if (!entity_on_rq(pse))
+             return;
+#endif

Ideally that #ifdef'ery would go away too.

This can 100% go away (and is already in the #ifdefs), but it will always be true in the !BANDWIDTH case, so it's a micro-overhead. Accompanying micro-optimization isn't really needed :)

Quoted 18 lines

kernel/sched_fair.c static bool yield_to_task_fair(struct rq · line 2163

Quoted 12 lines
kernel/sched_fair.c +2 -1
       if (sched_feat(NEXT_BUDDY) && scale && !(wake_flags & WF_FORK))
               set_next_buddy(pse);
 
@@ -2060,7 +2158,8 @@ static bool yield_to_task_fair(struct rq
  {
       struct sched_entity *se = &p->se;
 
-     if (!se->on_rq)
+     /* ensure entire hierarchy is on rq (e.g. running & not throttled) */
+     if (!entity_on_rq(se))
               return false;

like here..

Quoted 3 lines
kernel/sched_fair.c +0 -0
       /* Tell the scheduler that we'd really like pse to run next. */
@@ -2280,7 +2379,8 @@ static void update_shares(int cpu)
 
Quoted 8 lines

kernel/sched_fair.c static void update_shares(int cpu) · line 2383

Quoted 5 lines
kernel/sched_fair.c +2 -1
       rcu_read_lock();
       for_each_leaf_cfs_rq(rq, cfs_rq)
-             update_shares_cpu(cfs_rq->tg, cpu);
+             if (!cfs_rq_throttled(cfs_rq))
+                     update_shares_cpu(cfs_rq->tg, cpu);

This wants extra braces

Fixed

Quoted 20 lines
Quoted 18 lines
kernel/sched_fair.c +3 -2
       rcu_read_unlock();
  }
 
@@ -2304,9 +2404,10 @@ load_balance_fair(struct rq *this_rq, in
               u64 rem_load, moved_load;
 
               /*
-              * empty group
+              * empty group or throttled cfs_rq
                */
-             if (!busiest_cfs_rq->task_weight)
+             if (!busiest_cfs_rq->task_weight ||
+                             cfs_rq_throttled(busiest_cfs_rq))
                       continue;
 
               rem_load = (u64)rem_load_move * busiest_weight;
#5 lore raw

Re: [CFS Bandwidth Control v4 1/7] sched: introduce primitives to account for CFS bandwidth tracking

In reply to Peter Zijlstra
Quoted 17 lines · Peter Zijlstra

kernel/sched.c struct cfs_rq; · line 258

Quoted 12 lines · Paul Turner
kernel/sched.c +8 -0
@@ -245,6 +248,15 @@ struct cfs_rq;
 
  static LIST_HEAD(task_groups);
 
+#ifdef CONFIG_CFS_BANDWIDTH
+struct cfs_bandwidth {
+     raw_spinlock_t          lock;
+     ktime_t                 period;
+     u64                     runtime, quota;
+     struct hrtimer          period_timer;
+};
+#endif

If you write that as:

Quoted 6 lines

struct cfs_bandwidth {
#ifdef CONFIG_CFS_BANDWIDTH
       ...
#endif
};

While I prefer (entirely subjectively) making the #ifdef's in cfs_rq explicit; I have no real objection and this lets us kill #ifdefs around init_cfs_bandwidth (since it does reference the member).

Done.

Quoted 6 lines
Quoted 6 lines
kernel/sched.c +0 -0
  /* task group related information */
  struct task_group {
       struct cgroup_subsys_state css;
@@ -276,6 +288,10 @@ struct task_group {
  #ifdef CONFIG_SCHED_AUTOGROUP
       struct autogroup *autogroup;
Quoted 9 lines

kernel/sched.c struct task_group { · line 295

Quoted 6 lines
kernel/sched.c +4 -0
  #endif
+
+#ifdef CONFIG_CFS_BANDWIDTH
+     struct cfs_bandwidth cfs_bandwidth;
+#endif
  };

You can avoid the #ifdef'ery here

Done

Quoted 72 lines
Quoted 56 lines
kernel/sched.c +53 -0
  /* task_group_lock serializes the addition/removal of task groups */
@@ -370,9 +386,76 @@ struct cfs_rq {
 
+#ifdef CONFIG_CFS_BANDWIDTH
+static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun);
+
+static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
+{
+     struct cfs_bandwidth *cfs_b =
+             container_of(timer, struct cfs_bandwidth, period_timer);
+     ktime_t now;
+     int overrun;
+     int idle = 0;
+
+     for (;;) {
+             now = hrtimer_cb_get_time(timer);
+             overrun = hrtimer_forward(timer, now, cfs_b->period);
+
+             if (!overrun)
+                     break;
+
+             idle = do_sched_cfs_period_timer(cfs_b, overrun);
+     }
+
+     return idle ? HRTIMER_NORESTART : HRTIMER_RESTART;
+}
+
+static
+void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b, u64 quota, u64 period)
+{
+     raw_spin_lock_init(&cfs_b->lock);
+     cfs_b->quota = cfs_b->runtime = quota;
+     cfs_b->period = ns_to_ktime(period);
+
+     hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+     cfs_b->period_timer.function = sched_cfs_period_timer;
+}
+
+static
+void init_cfs_rq_quota(struct cfs_rq *cfs_rq)
+{
+     cfs_rq->quota_used = 0;
+     if (cfs_rq->tg->cfs_bandwidth.quota == RUNTIME_INF)
+             cfs_rq->quota_assigned = RUNTIME_INF;
+     else
+             cfs_rq->quota_assigned = 0;
+}
+
+static void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+     if (cfs_b->quota == RUNTIME_INF)
+             return;
+
+     if (hrtimer_active(&cfs_b->period_timer))
+             return;
+

kernel/sched.c struct cfs_rq { · line 449

Quoted 10 lines
kernel/sched.c +10 -0
+     raw_spin_lock(&cfs_b->lock);
+     start_bandwidth_timer(&cfs_b->period_timer, cfs_b->period);
+     raw_spin_unlock(&cfs_b->lock);
+}
+
+static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+     hrtimer_cancel(&cfs_b->period_timer);
+}
+#endif

and #else

stubs
#endif

Quoted 13 lines

kernel/sched.c static void init_tg_cfs_entry(struct tas · line 8126

Quoted 10 lines
kernel/sched.c +3 -0
  /* Real-Time classes' related field in a runqueue: */
  struct rt_rq {
       struct rt_prio_array active;
@@ -8038,6 +8121,9 @@ static void init_tg_cfs_entry(struct tas
       tg->cfs_rq[cpu] = cfs_rq;
       init_cfs_rq(cfs_rq, rq);
       cfs_rq->tg = tg;
+#ifdef CONFIG_CFS_BANDWIDTH
+     init_cfs_rq_quota(cfs_rq);
+#endif

also avoids #ifdef'ery here

Done

Quoted 4 lines
Quoted 4 lines
kernel/sched.c +0 -0
       tg->se[cpu] = se;
       /* se could be NULL for root_task_group */
@@ -8173,6 +8259,10 @@ void __init sched_init(void)
                * We achieve this by letting root_task_group's tasks sit
Quoted 9 lines

kernel/sched.c void __init sched_init(void) · line 8265

Quoted 6 lines
kernel/sched.c +4 -0
                * directly in rq->cfs (i.e root_task_group->se[] = NULL).
                */
+#ifdef CONFIG_CFS_BANDWIDTH
+             init_cfs_bandwidth(&root_task_group.cfs_bandwidth,
+                             RUNTIME_INF, sched_cfs_bandwidth_period);
+#endif

and here

Done

Quoted 7 lines
Quoted 7 lines
kernel/sched.c +0 -0
               init_tg_cfs_entry(&root_task_group, &rq->cfs, NULL, i, NULL);
  #endif /* CONFIG_FAIR_GROUP_SCHED */
 
@@ -8415,6 +8505,10 @@ static void free_fair_sched_group(struct
  {
       int i;
 
Quoted 6 lines

kernel/sched.c static void free_fair_sched_group(struct · line 8510

Quoted 3 lines
kernel/sched.c +3 -0
+#ifdef CONFIG_CFS_BANDWIDTH
+     destroy_cfs_bandwidth(&tg->cfs_bandwidth);
+#endif

and here

Done

Quoted 6 lines
Quoted 6 lines
kernel/sched.c +0 -0
       for_each_possible_cpu(i) {
               if (tg->cfs_rq)
                       kfree(tg->cfs_rq[i]);
@@ -8442,7 +8536,10 @@ int alloc_fair_sched_group(struct task_g
               goto err;
 
Quoted 9 lines

kernel/sched.c int alloc_fair_sched_group(struct task_g · line 8542

Quoted 6 lines
kernel/sched.c +4 -1
       tg->shares = NICE_0_LOAD;
-
+#ifdef CONFIG_CFS_BANDWIDTH
+     init_cfs_bandwidth(&tg->cfs_bandwidth, RUNTIME_INF,
+                     sched_cfs_bandwidth_period);
+#endif

and here

Done

Quoted 74 lines
Quoted 32 lines
kernel/sched.c +24 -0
       for_each_possible_cpu(i) {
               rq = cpu_rq(i);
 
@@ -9107,6 +9204,116 @@ static u64 cpu_shares_read_u64(struct cg
 
       return (u64) tg->shares;
  }
+
+#ifdef CONFIG_CFS_BANDWIDTH
+static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
+{
+     int i;
+     static DEFINE_MUTEX(mutex);
+
+     if (tg == &root_task_group)
+             return -EINVAL;
+
+     if (!period)
+             return -EINVAL;
+
+     /*
+      * Ensure we have at least one tick of bandwidth every period.  This is
+      * to prevent reaching a state of large arrears when throttled via
+      * entity_tick() resulting in prolonged exit starvation.
+      */
+     if (NS_TO_JIFFIES(quota) < 1)
+             return -EINVAL;
+
+     mutex_lock(&mutex);
+     raw_spin_lock_irq(&tg->cfs_bandwidth.lock);
+     tg->cfs_bandwidth.period = ns_to_ktime(period);

kernel/sched.c static u64 cpu_shares_read_u64(struct cg · line 9240

Quoted 10 lines
kernel/sched.c +10 -0
+     tg->cfs_bandwidth.runtime = tg->cfs_bandwidth.quota = quota;
+     raw_spin_unlock_irq(&tg->cfs_bandwidth.lock);
+
+     for_each_possible_cpu(i) {
+             struct cfs_rq *cfs_rq = tg->cfs_rq[i];
+             struct rq *rq = rq_of(cfs_rq);
+
+             raw_spin_lock_irq(&rq->lock);
+             init_cfs_rq_quota(cfs_rq);
+             raw_spin_unlock_irq(&rq->lock);

Any particular reason you didn't mirror rt_rq->rt_runtime_lock?

Quoted 29 lines
kernel/sched.c +5 -0
+     }
+     mutex_unlock(&mutex);
+
+     return 0;
+}
 
 

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +9 -0
@@ -88,6 +88,15 @@ const_debug unsigned int sysctl_sched_mi
   */
  unsigned int __read_mostly sysctl_sched_shares_window = 10000000UL;
 
+
+#ifdef CONFIG_CFS_BANDWIDTH
+/*
+ * default period for cfs group bandwidth.
+ * default: 0.5s, units: nanoseconds
+ */
+static u64 sched_cfs_bandwidth_period = 500000000ULL;
+#endif
+
  static const struct sched_class fair_sched_class;
 
  /**************************************************************
@@ -397,6 +406,9 @@ static void __enqueue_entity(struct cfs_
 
Quoted 10 lines

kernel/sched_fair.c static void __enqueue_entity(struct cfs_ · line 412

Quoted 6 lines
kernel/sched_fair.c +3 -0
       rb_link_node(&se->run_node, parent, link);
       rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
+#ifdef CONFIG_CFS_BANDWIDTH
+     start_cfs_bandwidth(&cfs_rq->tg->cfs_bandwidth);
+#endif
  }

This really needs to life elsewhere, __*_entity() functions are for rb-tree muck.

Moved to enqueue_entity

Quoted 4 lines
Quoted 1 line
kernel/sched_fair.c +0 -0
  static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
#56 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

In reply to Peter Zijlstra
Quoted 6 lines · Peter Zijlstra
Quoted 4 lines · Paul Turner
kernel/sched.c +0 -0
@@ -1846,6 +1846,11 @@ static const struct sched_class rt_sched
 
  #include "sched_stats.h"
 
Quoted 8 lines

kernel/sched.c static const struct sched_class rt_sched · line 1852

Quoted 4 lines
kernel/sched.c +4 -0
+static void mod_nr_running(struct rq *rq, long delta)
+{
+     rq->nr_running += delta;
+}

I personally don't see much use in such trivial wrappers.. if you're going to rework all the nr_running stuff you might as well remove all of that.

I'm ok with that, I was trying to preserve some of the existing encapsulation but there isn't a need for it.

Will do.

Quoted 96 lines
Quoted 41 lines

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +25 -0
@@ -81,6 +81,8 @@ unsigned int normalized_sysctl_sched_wak
 
  const_debug unsigned int sysctl_sched_migration_cost = 500000UL;
 
+static void account_hier_tasks(struct sched_entity *se, int delta);
+
  /*
   * The exponential sliding  window over which load is averaged for shares
   * distribution.
@@ -933,6 +935,40 @@ static inline void update_entity_shares_
  }
  #endif /* CONFIG_FAIR_GROUP_SCHED */
 
+#ifdef CONFIG_CFS_BANDWIDTH
+/* maintain hierarchal task counts on group entities */
+static void account_hier_tasks(struct sched_entity *se, int delta)
+{
+     struct rq *rq = rq_of(cfs_rq_of(se));
+     struct cfs_rq *cfs_rq;
+
+     for_each_sched_entity(se) {
+             /* a throttled entity cannot affect its parent hierarchy */
+             if (group_cfs_rq(se) && cfs_rq_throttled(group_cfs_rq(se)))
+                     break;
+
+             /* we affect our queuing entity */
+             cfs_rq = cfs_rq_of(se);
+             cfs_rq->h_nr_tasks += delta;
+     }
+
+     /* account for global nr_running delta to hierarchy change */
+     if (!se)
+             mod_nr_running(rq, delta);
+}
+#else
+/*

kernel/sched_fair.c static inline void update_entity_shares_ · line 970

Quoted 10 lines
kernel/sched_fair.c +10 -0
+ * In the absence of group throttling, all operations are guaranteed to be
+ * globally visible at the root rq level.
+ */
+static void account_hier_tasks(struct sched_entity *se, int delta)
+{
+     struct rq *rq = rq_of(cfs_rq_of(se));
+
+     mod_nr_running(rq, delta);
+}
+#endif

While Balbir suggested expanding the _hier_ thing, I'd suggest to simply drop it altogether, way too much typing ;-), but that is if you cannot get rid of the extra hierarchy iteration, see below.

Quoted 40 lines
kernel/sched_fair.c +6 -0
+
  static void enqueue_sleeper(struct cfs_rq *cfs_rq, struct sched_entity *se)
  {
  #ifdef CONFIG_SCHEDSTATS
@@ -1428,6 +1464,7 @@ enqueue_task_fair(struct rq *rq, struct
               update_cfs_shares(cfs_rq);
       }
 
+     account_hier_tasks(&p->se, 1);
       hrtick_update(rq);
  }
 
@@ -1461,6 +1498,7 @@ static void dequeue_task_fair(struct rq
               update_cfs_shares(cfs_rq);
       }
 
+     account_hier_tasks(&p->se, -1);
       hrtick_update(rq);
  }
 
@@ -1488,6 +1526,8 @@ static u64 tg_request_cfs_quota(struct t
       return delta;
  }
 
+static void account_hier_tasks(struct sched_entity *se, int delta);
+
  static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
  {
       struct sched_entity *se;
@@ -1507,6 +1547,7 @@ static void throttle_cfs_rq(struct cfs_r
       if (!se->on_rq)
               goto out_throttled;
 
+     account_hier_tasks(se, -cfs_rq->h_nr_tasks);
       for_each_sched_entity(se) {
               struct cfs_rq *cfs_rq = cfs_rq_of(se);
 
@@ -1541,6 +1582,7 @@ static void unthrottle_cfs_rq(struct cfs
       cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;
 
Quoted 9 lines

kernel/sched_fair.c static void unthrottle_cfs_rq(struct cfs · line 1588

Quoted 5 lines
kernel/sched_fair.c +1 -0
       cfs_rq->throttled = 0;
+     account_hier_tasks(se, cfs_rq->h_nr_tasks);
       for_each_sched_entity(se) {
               if (se->on_rq)
                       break;

All call-sites are right next to a for_each_sched_entity() iteration, is there really no way to fold those loops?

I was trying to avoid some duplication since many of those for_each iterations are partial and I didn't want to dump the same loop for the remnants everywhere.

However, thinking about it I think this can be cleaned up and refined to by having account_hier iterate from wherever they finish and avoiding that nastiness.

Quoted 21 lines
Quoted 21 lines

Index: tip/kernel/sched_rt.c
===================================================================

kernel/sched_rt.c +4 -0
@@ -906,6 +906,8 @@ enqueue_task_rt(struct rq *rq, struct ta
 
       if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
               enqueue_pushable_task(rq, p);
+
+     inc_nr_running(rq);
  }
 
  static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
@@ -916,6 +918,8 @@ static void dequeue_task_rt(struct rq *r
       dequeue_rt_entity(rt_se);
 
       dequeue_pushable_task(rq, p);
+
+     dec_nr_running(rq);
  }
 
Quoted 10 lines

kernel/sched_rt.c static void print_rt_stats(struct seq_fi · line 1789

Quoted 5 lines
kernel/sched_rt.c +0 -0
  /*
@@ -1783,4 +1787,3 @@ static void print_rt_stats(struct seq_fi
       rcu_read_unlock();
  }
  #endif /* CONFIG_SCHED_DEBUG */

You mentioned something about -rt having the same problem, yet you don't fix it.. tskkk :-)

Yeah I agree :) -- I was planning on fixing this in a follow-up [honest!] as it's not as important since it doesn't affect idle balancing to the same magnitude. I wanted to first air the notion of hierarchal task accounting in one of the schedulers then mirror the support across the other schedulers with consensus reached.

I can make that part of this series if you'd prefer.

Quoted 1 line
#47 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

In reply to Peter Zijlstra
Quoted 8 lines · Peter Zijlstra
Quoted 3 lines · Paul Turner

+       raw_spin_lock(&cfs_b->lock);
+       cfs_b->throttled_time += (rq->clock - cfs_rq->throttled_timestamp);
+       raw_spin_unlock(&cfs_b->lock);

That seems to put the cost of things on the wrong side. Read is rare, update is frequent, and you made the frequent thing the most expensive one.

Hum.. the trade-off here is non-trivial I think

- This update is only once per-quota period (*if* we throttled within that period). This places the frequency in the 10s-100s of ms range.
- Sampling would probably occur on an order of once a second (assuming some enterprise management system that cares about these statistics).

If we make the update cheaper by moving this per-cpu, then yes the updates are cheaper but the reads now having per-cpu cost makes the overall cost about the same (multiplying frequency by delta cost).

We could move the global accrual to an atomic, but this isn't any cheaper given that this lock shouldn't be
contended.

Quoted 3 lines
#10 lore raw

Re: [CFS Bandwidth Control v4 2/7] sched: accumulate per-cfs_rq cpu usage

In reply to Peter Zijlstra
Quoted 13 lines · Peter Zijlstra

kernel/sched_fair.c static void update_curr(struct cfs_rq *c · line 637

Quoted 8 lines · Paul Turner
kernel/sched_fair.c +3 -0
@@ -609,6 +631,9 @@ static void update_curr(struct cfs_rq *c
               cpuacct_charge(curtask, delta_exec);
               account_group_exec_runtime(curtask, delta_exec);
       }
+#ifdef CONFIG_CFS_BANDWIDTH
+     account_cfs_rq_quota(cfs_rq, delta_exec);
+#endif
  }

Not too hard to make the #ifdef'ery go away I'd guess.

Done

Quoted 14 lines
Quoted 14 lines

 static inline void

kernel/sched_fair.c +9 -0
@@ -1382,6 +1407,43 @@ static void dequeue_task_fair(struct rq
  }
 
  #ifdef CONFIG_CFS_BANDWIDTH
+static u64 tg_request_cfs_quota(struct task_group *tg)
+{
+     struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);
+     u64 delta = 0;
+
+     if (cfs_b->runtime > 0 || cfs_b->quota == RUNTIME_INF) {
+             raw_spin_lock(&cfs_b->lock);
+             /*
+              * it's possible a bandwidth update has changed the global
Quoted 9 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1422

Quoted 4 lines
kernel/sched_fair.c +4 -0
+              * pool.
+              */
+             if (cfs_b->quota == RUNTIME_INF)
+                     delta = sched_cfs_bandwidth_slice();

Why do we bother at all when there's infinite time? Shouldn't the action that sets it to infinite also make cfs_rq->quota_assinged to to RUNTIME_INF, in which case the below check will make it all go away?

The request for bandwidth might be racing with an entity's request for bandwidth.

e.g. someone updates cpu.cfs_quota_us to infinite while there's bandwidth distribution in flight.

In this case we need to return some sane value so that the thread requesting bandwidth can complete that operation (releasing the lock which will then be taken to set quota_assigned to INF).

But more importantly we don't want to decrement the value doled out FROM cfs_b->runtime since that would change it from the magic RUNTIME_INF. That's why the check exists.

Quoted 10 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1431

Quoted 9 lines
kernel/sched_fair.c +9 -0
+             else {
+                     delta = min(cfs_b->runtime,
+                                     sched_cfs_bandwidth_slice());
+                     cfs_b->runtime -= delta;
+             }
+             raw_spin_unlock(&cfs_b->lock);
+     }
+     return delta;
+}
Quoted 6 lines

Also, shouldn't this all try and steal time from other cpus when the global limit ran out? Suppose you have say 24 cpus, and you had a short burst where all 24 cpus had some runtime, so you distribute 240ms. But 23 of those cpus only ran for 0.5ms, leaving 23.5ms of unused time on 23 cpus while your one active cpu will then throttle.

In practice this only affects the first period since that slightly stale bandwidth is then available on those other 23 cpus the next time a micro-burst occurs. In testing this has resulted in very stable performance and "smooth" perturbations that resemble hardcapping by affinity (for integer points).

The notion of stealing could certainly be introduced, the juncture of reaching the zero point here would be a possible place to consider that (although we would need to do a steal that avoids the asymptotic convergence problem of RT).

I think returning (most) of the bandwidth to the global pool on (voluntary) dequeue is a more scalable solution

Quoted 3 lines

I would much rather see all the accounting tight first and optimize later than start with leaky stuff and try and plug holes later.

The complexity this introduces is non-trivial since the idea of returning quota to the pool means you need to introduce the notion of when that quota came to life (otherwise you get leaks in the reverse direction!) -- as well as reversing some of the lock ordering.

While generations do this they don't greatly increase the efficacy and I think there is value in performing the detailed review we are doing now in isolation of that.

It's also still consistent regarding leakage since in that in any N consecutive periods the maximum additional quota (by a user abusing this) that can be received is N+1. Does the complexity trade-off merit improving this bound at this point?

Quoted 8 lines
Quoted 8 lines
kernel/sched_fair.c +8 -0
+
+static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
+             unsigned long delta_exec)
+{
+     if (cfs_rq->quota_assigned == RUNTIME_INF)
+             return;
+
+     cfs_rq->quota_used += delta_exec;
Quoted 8 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1445

Quoted 6 lines
kernel/sched_fair.c +6 -0
+
+     if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+             return;
+
+     cfs_rq->quota_assigned += tg_request_cfs_quota(cfs_rq->tg);
+}

So why isn't this hierarchical?,

It is naturally (since charging occurs within the existing hierarchal accounting)

Quoted 3 lines

also all this positive quota stuff
looks weird, why not decrement and try to supplement when negative?

I thought I had a good reason for this.. at least I remember at one point I think I did.. but I cannot see any need for it in the current form. I will revise it to a single decremented quota_remaining.

#22 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Peter Zijlstra
Quoted 23 lines · Peter Zijlstra
Quoted 22 lines · Bharata B Rao

Hi Peter,

I will only answer a couple of your questions and let Paul clarify the rest...

Quoted 17 lines · Peter Zijlstra
Quoted 14 lines · Paul Turner
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct
                   break;
           cfs_rq = cfs_rq_of(se);
           enqueue_entity(cfs_rq, se, flags);
+         /* don't continue to enqueue if our parent is throttled */
+         if (cfs_rq_throttled(cfs_rq))
+                 break;
           flags = ENQUEUE_WAKEUP;
   }
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq
           cfs_rq = cfs_rq_of(se);
           dequeue_entity(cfs_rq, se, flags);
 
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
kernel/sched_fair.c +5 -2
-         /* Don't dequeue parent if it has other entities besides us */
-         if (cfs_rq->load.weight)
+         /*
+          * Don't dequeue parent if it has other entities besides us,
+          * or if it is throttled
+          */
+         if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
                   break;
           flags |= DEQUEUE_SLEEP;
   }
Quoted 1 line
Quoted 1 line

How could we even be running if our parent was throttled?

The only way this can happen is if we are on our way out. The example given doesn't apply to this case I don't think

Quoted 10 lines
Quoted 9 lines

The task isn't running actually. One of its parents up in the heirarchy has been throttled and been already dequeued. Now this task sits on its immediate parent's runqueue which isn't throttled but not really running also since the hierarchy is throttled.
In this situation, load balancer can try to pull
this task. When that happens, load balancer tries to dequeue it and this check will ensure that we don't attempt to dequeue a group entity in our hierarchy which has already been dequeued.

Quoted 2 lines

That's insane, its throttled, that means it should be dequeued and should thus invisible for the load-balancer.

I agree. We ensure this does not happen by making the h_load zero. Something I thought I was doing but apparently not, will fix in repost.

Quoted 3 lines

load-balancer will try and move tasks around to balance load, but all in vain, it'll move phantom loads around and get most confused at best.

Yeah this shouldn't happen, I don't think this example is a valid one.

Quoted 21 lines

Pure and utter suckage if you ask me.

Quoted 12 lines
Quoted 11 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 8 lines
kernel/sched_fair.c +2 -1
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct
 
   cfs_rq->quota_used += delta_exec;
 
- if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+ if (cfs_rq_throttled(cfs_rq) ||
+         cfs_rq->quota_used < cfs_rq->quota_assigned)
           return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

Quoted 6 lines

When a cfs_rq is throttled, its representative se (and all its parent se's) get dequeued and the task is marked for resched. But the task entity is still on its throttled parent's cfs_rq (=> task->se.on_rq = 1). Next during put_prev_task_fair(), we enqueue the task back on its throttled parent's cfs_rq at which time we end up calling update_curr() on throttled cfs_rq. This check would help us bail out from that situation.

Quoted 4 lines

But why bother with this early exit? At worst you'll call tg_request_cfs_quota() in vain, at best you'll find there is runtime because the period tick just happened on another cpu and you're good to go, yay!

It's for the non-preemptible case where we could be running for non trivial time after reschedule()

Considering your second point I suppose there could be a micro-benefit in checking in case the period tick did just happen to occur and then self unthrottling... but I don't think it's really worth it.

Quoted 3 lines
#21 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Peter Zijlstra
Quoted 33 lines · Peter Zijlstra
Quoted 24 lines · Bharata B Rao
Quoted 8 lines · Peter Zijlstra
Quoted 6 lines · Bharata B Rao

While I admit that our load balancing semantics wrt thorttled entities are not consistent (we don't allow pulling of tasks directly from throttled cfs_rqs, while allow pulling of tasks from a throttled hierarchy as in the above case), I am beginning to think if it works out to be advantageous. Is there a chance that the task gets to run on other CPU where the hierarchy isn't throttled since runtime is still available ?

Quoted 6 lines

Possible yes, but the load-balancer doesn't know about that, not should it (its complicated, and broken, enough, no need to add more cruft to it).

I'm starting to think you all should just toss all this and start over, its just too smelly.

Hmm... You have brought up 3 concerns:

1. Hierarchy semantics

If you look at the heirarchy semantics we currently have while ignoring the load balancer interactions for a moment, I guess what we have is a reasonable one.

Quoted 7 lines

- Only group entities are throttled
- Throttled entities are taken off the runqueue and hence they never get picked up for scheduling.
- New or child entites are queued up to the throttled entities and not further up. As I said in another thread, having the tree intact and correct underneath the throttled entity allows us to rebuild the hierarchy during unthrottling with least amount of effort.

Quoted 3 lines

It also gets you into all that load-balancer mess, and I'm not going to let you off lightly there.

I think the example was a little cuckoo. As you say, it's dequeued and invisible to the load balancer.

The special case of block->wakeup->throttle->put only exists for the current task which is ineligible for non-active load-balance anyway.

Quoted 7 lines
Quoted 2 lines

- Group entities in a hierarchy are throttled independent of each other based on their bandwidth specification.

That's missing out quite a few details.. for one there is no mention of hierarchical implication of/constraints on bandwidth, can children have more bandwidth than their parent (I hope not).

I wasn't planning to enforce it since I believe there is value in non-conformant constraints:

Consider:

- I have some application that I want to limit to 3 cpus I have a 2 workers in that application, across a period I would like those workers to use a maximum of say 2.5 cpus each (suppose they serve some sort of co-processor request per user and we want to prevent a single user eating our entire limit and starving out everything else).

The goal in this case is not preventing over-subscription, but ensuring that some part threads is not allowed to blow our entire quota, while not destroying the (relatively) work-conserving aspect of its performance in general.

The above occurs sufficiently often that at the very least I think conformance checking would have to be gated by a sysctl so that this use case is still enabled.

- There's also the case of "I want to manage a newly abusive user, being smart I've given his hierarchy a unique root so that I can constrain them."
A non-conformant constraint avoids the adversarial problem of having to find and bring all of their set (possibly maliciously large) limits within the global limit I want to impose upon them.

My viewpoint was that if some idiot wants to set up such a tree (unintentionally) it's their own damn fault but I suppose we should at least give them a safety :) I'll add it.

Quoted 7 lines
Quoted 3 lines

2. Handling of throttled entities by load balancer

This definetely needs to improve and be more consistent. We can work on this.

Feh, improve is being nice about it, it needs a complete overhaul, the current situation is a cobbled together leaky mess.

I think as long as the higher level semantics are correct and throttling happens /sanely/ this is a non-issue.

Quoted 6 lines
Quoted 5 lines

3. per-cgroup vs global period specification

I thought per-cgroup specification would be most flexible and hence started out with that. This would allow groups/workloads/VMs to define their own bandwidth rate.

Quoted 8 lines

Most flexible yes, most 'interesting' too, now if you consider running a child task is also running the parent entity and therefore you're consuming bandwidth up the entire hierarchy, what happens when the parent has a much larger period than the child?

In that case your child doesn't get ran while the parent is throttled, and the child's period is violated.

There are definitely cases where this is both valid and useful. I think gating conformancy allows for both (especially if it defaults to "on").

Quoted 7 lines
Quoted 2 lines

Let us know if you have other design concerns besides these.

Yeah, that weird time accounting muck, bandwidth should decrease on usage and incremented on replenishment, this gets you 0 as the natural boundary between credit and debt, no need to keep two variables.

Yes, agreed! Fixing :)

Quoted 3 lines

Also, the above just about covers all the patch set does, isn't that enough justification to throw the thing out and start over?

#48 lore raw

Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfs bandwidth control statistics

In reply to Paul Turner
Quoted 10 lines · Paul Turner
Quoted 8 lines · Peter Zijlstra

kernel/sched_fair.c static void throttle_cfs_rq(struct cfs_r · line 1538

Quoted 3 lines · Paul Turner
kernel/sched_fair.c +3 -0
+       raw_spin_lock(&cfs_b->lock);
+       cfs_b->throttled_time += (rq->clock - cfs_rq->throttled_timestamp);
+       raw_spin_unlock(&cfs_b->lock);

That seems to put the cost of things on the wrong side. Read is rare, update is frequent, and you made the frequent thing the most expensive one.

Quoted 6 lines

Hum.. the trade-off here is non-trivial I think

- This update is only once per-quota period (*if* we throttled within that period). This places the frequency in the 10s-100s of ms range.
- Sampling would probably occur on an order of once a second (assuming some enterprise management system that cares about these statistics).

Ugh,. people are really polling state like that? If the event is rare pushing state is much saner.

#66 lore raw
In reply to a message not in the archive
Quoted 24 lines · jacob pan
Quoted 9 lines · On Tue, 15 Feb 2011 19:18:31 -0800 Paul Turner <[email protected]> wrote:

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Your patches provide a very useful but slightly different feature for what we need to manage idle time in order to save power. What we need is kind of a quota/period in terms of idle time. I have been playing with your patches and noticed that when the cgroup cpu usage exceeds the quota the effect of throttling is similar to what I have been trying to do with freezer subsystem. i.e. freeze and thaw at given period and percentage runtime.
https://lkml.org/lkml/2011/2/15/314

Quoted 3 lines

Have you thought about adding such feature (please see detailed description in the link above) to your patches?

So reading the description it seems like rooting everything in a 'freezer' container and then setting up a quota of

(1 - frozen_percentage) * nr_cpus * frozen_period * sec_to_usec

on a period of

frozen_period * sec_to_usec

Would provide the same functionality. Is there other unduplicated functionality beyond this?

One thing that does seem undesirable about your approach is (as it seems to be described) threads will not be able to take advantage of naturally occurring idle cycles and will incur a potential performance penalty even at use << frozen_percentage.

e.g. From your post

       |  |<-- 90% frozen -     ->|  |                               |  |
____|  |________________x_|  |__________________|  |_____
        |<---- 5 seconds     ---->|

Suppose no threads active until the wake up at x, suppose there is an accompanying 1 second of work for that thread to do. That execution time will be dilated to ~1.5 seconds (as it will span the 0.5 seconds the freezer will stall for). But the true usage for this period is ~20% <<< 90%

Quoted 4 lines

Thanks,

Jacob

#57 lore raw

Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER

In reply to Paul Turner
Quoted 6 lines · Paul Turner

Yeah I agree :) -- I was planning on fixing this in a follow-up [honest!] as it's not as important since it doesn't affect idle balancing to the same magnitude. I wanted to first air the notion of hierarchal task accounting in one of the schedulers then mirror the support across the other schedulers with consensus reached.

Right, I think I once argued against this, but the effect on a lot of things are against me, so lets do this.

#11 lore raw

Re: [CFS Bandwidth Control v4 2/7] sched: accumulate per-cfs_rq cpu usage

In reply to Paul Turner
Quoted 19 lines · Paul Turner
Quoted 10 lines
Quoted 10 lines

#ifdef CONFIG_CFS_BANDWIDTH

kernel/sched_fair.c +9 -0
+static u64 tg_request_cfs_quota(struct task_group *tg)
+{
+     struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);
+     u64 delta = 0;
+
+     if (cfs_b->runtime > 0 || cfs_b->quota == RUNTIME_INF) {
+             raw_spin_lock(&cfs_b->lock);
+             /*
+              * it's possible a bandwidth update has changed the global
Quoted 8 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1422

Quoted 4 lines
kernel/sched_fair.c +4 -0
+              * pool.
+              */
+             if (cfs_b->quota == RUNTIME_INF)
+                     delta = sched_cfs_bandwidth_slice();

Why do we bother at all when there's infinite time? Shouldn't the action that sets it to infinite also make cfs_rq->quota_assinged to to RUNTIME_INF, in which case the below check will make it all go away?

Quoted 3 lines

But more importantly we don't want to decrement the value doled out FROM cfs_b->runtime since that would change it from the magic RUNTIME_INF. That's why the check exists.

Ah, quite so.

Quoted 31 lines
Quoted 10 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1431

Quoted 9 lines
kernel/sched_fair.c +9 -0
+             else {
+                     delta = min(cfs_b->runtime,
+                                     sched_cfs_bandwidth_slice());
+                     cfs_b->runtime -= delta;
+             }
+             raw_spin_unlock(&cfs_b->lock);
+     }
+     return delta;
+}
Quoted 6 lines

Also, shouldn't this all try and steal time from other cpus when the global limit ran out? Suppose you have say 24 cpus, and you had a short burst where all 24 cpus had some runtime, so you distribute 240ms. But 23 of those cpus only ran for 0.5ms, leaving 23.5ms of unused time on 23 cpus while your one active cpu will then throttle.

In practice this only affects the first period since that slightly stale bandwidth is then available on those other 23 cpus the next time a micro-burst occurs. In testing this has resulted in very stable performance and "smooth" perturbations that resemble hardcapping by affinity (for integer points).

The notion of stealing could certainly be introduced, the juncture of reaching the zero point here would be a possible place to consider that (although we would need to do a steal that avoids the asymptotic convergence problem of RT).

I think returning (most) of the bandwidth to the global pool on (voluntary) dequeue is a more scalable solution

Quoted 8 lines
Quoted 3 lines

I would much rather see all the accounting tight first and optimize later than start with leaky stuff and try and plug holes later.

The complexity this introduces is non-trivial since the idea of returning quota to the pool means you need to introduce the notion of when that quota came to life (otherwise you get leaks in the reverse direction!) -- as well as reversing some of the lock ordering.

Right, nasty that, RT doesn't suffer this because of the lack of over-commit.

Quoted 8 lines

While generations do this they don't greatly increase the efficacy and I think there is value in performing the detailed review we are doing now in isolation of that.

It's also still consistent regarding leakage since in that in any N consecutive periods the maximum additional quota (by a user abusing this) that can be received is N+1. Does the complexity trade-off merit improving this bound at this point?

Well, something yes, with N being potentially very large indeed these days we need some feedback.

One idea would be to keep a cpu mask in the bandwidth thing and setting the cpu when a cpu claims bandwidth from the global pool and iterate and clear the complete mask on tick.

That also limits the scope on where to look for stealing time.

Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
kernel/sched_fair.c +7 -0
+static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
+             unsigned long delta_exec)
+{
+     if (cfs_rq->quota_assigned == RUNTIME_INF)
+             return;
+
+     cfs_rq->quota_used += delta_exec;
Quoted 8 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1445

Quoted 6 lines
kernel/sched_fair.c +6 -0
+
+     if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+             return;
+
+     cfs_rq->quota_assigned += tg_request_cfs_quota(cfs_rq->tg);
+}

So why isn't this hierarchical?,

Quoted 2 lines

It is naturally (since charging occurs within the existing hierarchal accounting)

D'0h yes.. somehow I totally missed that.

#67 lore raw
In reply to Paul Turner
Quoted 26 lines · On Fri, 25 Feb 2011 02:03:54 -0800 Paul Turner <[email protected]> wrote:
Quoted 24 lines · jacob pan
Quoted 9 lines · On Tue, 15 Feb 2011 19:18:31 -0800 Paul Turner <[email protected]> wrote:

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Your patches provide a very useful but slightly different feature for what we need to manage idle time in order to save power. What we need is kind of a quota/period in terms of idle time. I have been playing with your patches and noticed that when the cgroup cpu usage exceeds the quota the effect of throttling is similar to what I have been trying to do with freezer subsystem. i.e. freeze and thaw at given period and percentage runtime.
https://lkml.org/lkml/2011/2/15/314

Quoted 9 lines
Quoted 3 lines

Have you thought about adding such feature (please see detailed description in the link above) to your patches?

So reading the description it seems like rooting everything in a 'freezer' container and then setting up a quota of

(1 - frozen_percentage) * nr_cpus * frozen_period * sec_to_usec

I guess you meant frozen_percentage is less than 1, i.e. 90 is .90. my code treat 90 as 90. just a clarification.

Quoted 6 lines

on a period of

frozen_period * sec_to_usec

Would provide the same functionality. Is there other unduplicated functionality beyond this?

Do you mean the same functionality as your patch? Not really, since my approach will stop the tasks based on hard time slices. But seems your patch will allow them to run if they don't exceed the quota. Am i missing something?
That is the only functionality difference i know.

Like the reviewer of freezer patch pointed out, it is a more logical fit to implement such feature in scheduler/yours in stead of freezer. So i am wondering if your patch can be expended to include limiting quota on real time.

I did a comparison study between CFS BW and freezer patch on skype with identical quota setting as you pointed out earlier. Both use 2 sec period and .2 sec quota (10%). Skype typically uses 5% of the CPU on my system when placing a call(below cfs quota) and it wakes up every 100ms to do some quick checks. Then I run skype in cpu then freezer cgroup (with all its children). Here is my result based on timechart and powertop.

patch name wakeups skype call?
------------------------------------------------------------------
CFS BW 10/sec yes
freezer 1/sec no

Skype might not be the best example to illustrate the real usage of the feature, but we are targeting mobile device where they are mostly off or often have only one application allowed in foreground. So we want to reduce wakeups coming from the tasks that are not in the foreground.

Quoted 10 lines

One thing that does seem undesirable about your approach is (as it seems to be described) threads will not be able to take advantage of naturally occurring idle cycles and will incur a potential performance penalty even at use << frozen_percentage.

e.g. From your post

       |  |<-- 90% frozen -     ->|  |
|  | ____|  |________________x_|  |__________________|  |_____
Quoted 8 lines
        |<---- 5 seconds     ---->|

Suppose no threads active until the wake up at x, suppose there is an accompanying 1 second of work for that thread to do. That execution time will be dilated to ~1.5 seconds (as it will span the 0.5 seconds the freezer will stall for). But the true usage for this period is ~20% <<< 90%

I agree my approach does not consider the natural cycle. But I am not sure if a thread can wake up at x when FROZEN.

#24 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Paul Turner
Quoted 16 lines · Paul Turner
Quoted 14 lines · Peter Zijlstra

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 9 lines · Paul Turner

+     update_cfs_load(cfs_rq, 0);

kernel/sched_fair.c +8 -0
+
+     /* prevent previous buddy nominations from re-picking this se */
+     clear_buddies(cfs_rq_of(se), se);
+
+     /*
+      * It's possible for the current task to block and re-wake before task
+      * switch, leading to a throttle within enqueue_task->update_curr()
+      * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

Quoted 2 lines

I'm not sure the example Bharata gave is correct -- I'm going to treat that discussion separately as it's not the intent here.

Just for the record, my examples were not given for the above question from Peter.

I answered two questions and I am tempted to stand by those until proven wrong :)

1. Why do we have cfs_rq_throtted() check in dequeue_task_fair() ? ( => How could we be running if our parent was throttled ?)

Consider the following hierarchy.

Root Group
|
|
Group 1 (Bandwidth constrained group)
|
|
Group 2 (Infinite runtime group)

Assume both the groups have tasks in them.

When Group 1 is throttled, its cfs_rq is marked throttled, and is removed from Root group's runqueue. But leaf tasks in Group 2 continue to be enqueued in Group 1's runqueue.

Load balancer kicks in on CPU A and figures out that it can pull a few tasks from CPU B (busiest_cpu). It iterates through all the task groups (load_balance_fair) and considers Group 2 also. It tries to pull a task from CPU B's cfs_rq for Group 2. I don't see anything that would prevent the load balancer from bailing out here. Note that Group 2 is technically not throttled, only its parent Group 1 is. Load balancer goes ahead and starts pulling individual tasks from Group 2's cfs_rq on CPU B. This results in dequeuing of task whose hierarchy is throttled.

When load balancer iterates through Group 1's cfs_rqs, the situation is different because we have already marked Group 1's cfs_rqs as throttled. And we check this in load_balance_fair() and bail out from pulling tasks from throttled hierarchy.

This is my understanding. Let me know what I miss. Specifically I would like to understand how do you ensure that load balancer doesn't consider tasks from throttled cfs_rqs for pulling.

2. Why there is cfs_rq_throttled() check in account_cfs_rq_quota() ?

In addition to the case you described, I believe the situation I described is also valid.

Regards,
Bharata.

#25 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

Quoted 17 lines · Bharata B Rao
Quoted 16 lines · Paul Turner
Quoted 14 lines · Peter Zijlstra

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 9 lines · Paul Turner

+     update_cfs_load(cfs_rq, 0);

kernel/sched_fair.c +8 -0
+
+     /* prevent previous buddy nominations from re-picking this se */
+     clear_buddies(cfs_rq_of(se), se);
+
+     /*
+      * It's possible for the current task to block and re-wake before task
+      * switch, leading to a throttle within enqueue_task->update_curr()
+      * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

Quoted 8 lines
Quoted 2 lines

I'm not sure the example Bharata gave is correct -- I'm going to treat that discussion separately as it's not the intent here.

Just for the record, my examples were not given for the above question from Peter.

I answered two questions and I am tempted to stand by those until proven wrong :)

This is important to get right, I'm happy to elaborate.

Quoted 2 lines

1. Why do we have cfs_rq_throtted() check in dequeue_task_fair() ?

The check is primarily needed because we could become throttled as part of a regular dequeue. At which point we bail because the parent dequeue is actually complete.

(Were it necessitated by load balance we could actually not do this and just perform a hierarchal check within load_balance_fair)

Quoted 2 lines

( => How could we be running if our parent was throttled ?)

The only way we can be running if our parent was throttled is if /we/ triggered that throttle and have been marked for re-schedule.

Quoted 10 lines

Consider the following hierarchy.

Root Group
  |
  |
Group 1 (Bandwidth constrained group)
  |
  |
Group 2 (Infinite runtime group)

Quoted 6 lines

Assume both the groups have tasks in them.

When Group 1 is throttled, its cfs_rq is marked throttled, and is removed from Root group's runqueue. But leaf tasks in Group 2 continue to be enqueued in Group 1's runqueue.

Yes, the hierarchy state is maintained in isolation.

Quoted 5 lines

Load balancer kicks in on CPU A and figures out that it can pull a few tasks from CPU B (busiest_cpu). It iterates through all the task groups (load_balance_fair) and considers Group 2 also. It tries to pull a task from CPU B's cfs_rq for Group 2. I don't see anything that would prevent the load balancer from bailing out here.

Per above, the descendants of a throttled group are also identified (and appropriately skipped) using h_load.

Quoted 3 lines

Note that Group 2 is technically
not throttled, only its parent Group 1 is. Load balancer goes ahead and starts pulling individual tasks from Group 2's cfs_rq on CPU B.

In general, not true -- load balancing against a throttled hierarchy is crazy[*].

Quoted 2 lines

This results in dequeuing of task whose hierarchy is throttled.

[*]: There is one edge case in which it may sanely occur:

Namely, if the load balance races with a throttle (since we don't take rq->locks until we start actually moving tasks). In this case it's still ok because the cached h_load ensures the load balancer is still working from a sane load view and it's as if we performed a minute re-ordering so it's as if the load-balance had occurred fractionally before the throttle instead of fractionally after.

Quoted 5 lines

When load balancer iterates through Group 1's cfs_rqs, the situation is different because we have already marked Group 1's cfs_rqs as throttled. And we check this in load_balance_fair() and bail out from pulling tasks from throttled hierarchy.

Quoted 9 lines

This is my understanding. Let me know what I miss. Specifically I would like to understand how do you ensure that load balancer doesn't consider tasks from throttled cfs_rqs for pulling.

2. Why there is cfs_rq_throttled() check in account_cfs_rq_quota() ?

In addition to the case you described, I believe the situation I described is also valid.

The point made above was that it's actually for any update that may (legitimately) occur as throttling can not always be aligned with eviction. The case you gave is one of several -- there's nothing particularly unique about it (nor did I actually disagree with it).

Quoted 3 lines

Regards,
Bharata.

#6 lore raw

Re: [CFS Bandwidth Control v4 1/7] sched: introduce primitives to account for CFS bandwidth tracking

In reply to Peter Zijlstra
Quoted 200 lines · Peter Zijlstra

kernel/sched.c struct cfs_rq; · line 258

Quoted 12 lines · Paul Turner
kernel/sched.c +8 -0
@@ -245,6 +248,15 @@ struct cfs_rq;
 
  static LIST_HEAD(task_groups);
 
+#ifdef CONFIG_CFS_BANDWIDTH
+struct cfs_bandwidth {
+     raw_spinlock_t          lock;
+     ktime_t                 period;
+     u64                     runtime, quota;
+     struct hrtimer          period_timer;
+};
+#endif

If you write that as:

struct cfs_bandwidth {
#ifdef CONFIG_CFS_BANDWIDTH
       ...
#endif
};

kernel/sched.c struct task_group { · line 295

Quoted 12 lines
kernel/sched.c +4 -0
  /* task group related information */
  struct task_group {
       struct cgroup_subsys_state css;
@@ -276,6 +288,10 @@ struct task_group {
  #ifdef CONFIG_SCHED_AUTOGROUP
       struct autogroup *autogroup;
  #endif
+
+#ifdef CONFIG_CFS_BANDWIDTH
+     struct cfs_bandwidth cfs_bandwidth;
+#endif
  };

You can avoid the #ifdef'ery here

Quoted 56 lines
kernel/sched.c +53 -0
  /* task_group_lock serializes the addition/removal of task groups */
@@ -370,9 +386,76 @@ struct cfs_rq {
 
+#ifdef CONFIG_CFS_BANDWIDTH
+static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun);
+
+static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
+{
+     struct cfs_bandwidth *cfs_b =
+             container_of(timer, struct cfs_bandwidth, period_timer);
+     ktime_t now;
+     int overrun;
+     int idle = 0;
+
+     for (;;) {
+             now = hrtimer_cb_get_time(timer);
+             overrun = hrtimer_forward(timer, now, cfs_b->period);
+
+             if (!overrun)
+                     break;
+
+             idle = do_sched_cfs_period_timer(cfs_b, overrun);
+     }
+
+     return idle ? HRTIMER_NORESTART : HRTIMER_RESTART;
+}
+
+static
+void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b, u64 quota, u64 period)
+{
+     raw_spin_lock_init(&cfs_b->lock);
+     cfs_b->quota = cfs_b->runtime = quota;
+     cfs_b->period = ns_to_ktime(period);
+
+     hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+     cfs_b->period_timer.function = sched_cfs_period_timer;
+}
+
+static
+void init_cfs_rq_quota(struct cfs_rq *cfs_rq)
+{
+     cfs_rq->quota_used = 0;
+     if (cfs_rq->tg->cfs_bandwidth.quota == RUNTIME_INF)
+             cfs_rq->quota_assigned = RUNTIME_INF;
+     else
+             cfs_rq->quota_assigned = 0;
+}
+
+static void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+     if (cfs_b->quota == RUNTIME_INF)
+             return;
+
+     if (hrtimer_active(&cfs_b->period_timer))
+             return;
+

kernel/sched.c struct cfs_rq { · line 449

Quoted 10 lines
kernel/sched.c +10 -0
+     raw_spin_lock(&cfs_b->lock);
+     start_bandwidth_timer(&cfs_b->period_timer, cfs_b->period);
+     raw_spin_unlock(&cfs_b->lock);
+}
+
+static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
+{
+     hrtimer_cancel(&cfs_b->period_timer);
+}
+#endif

and #else

stubs
#endif

kernel/sched.c static void init_tg_cfs_entry(struct tas · line 8126

Quoted 10 lines
kernel/sched.c +3 -0
  /* Real-Time classes' related field in a runqueue: */
  struct rt_rq {
       struct rt_prio_array active;
@@ -8038,6 +8121,9 @@ static void init_tg_cfs_entry(struct tas
       tg->cfs_rq[cpu] = cfs_rq;
       init_cfs_rq(cfs_rq, rq);
       cfs_rq->tg = tg;
+#ifdef CONFIG_CFS_BANDWIDTH
+     init_cfs_rq_quota(cfs_rq);
+#endif

also avoids #ifdef'ery here

kernel/sched.c void __init sched_init(void) · line 8265

Quoted 10 lines
kernel/sched.c +4 -0
       tg->se[cpu] = se;
       /* se could be NULL for root_task_group */
@@ -8173,6 +8259,10 @@ void __init sched_init(void)
                * We achieve this by letting root_task_group's tasks sit
                * directly in rq->cfs (i.e root_task_group->se[] = NULL).
                */
+#ifdef CONFIG_CFS_BANDWIDTH
+             init_cfs_bandwidth(&root_task_group.cfs_bandwidth,
+                             RUNTIME_INF, sched_cfs_bandwidth_period);
+#endif

and here

kernel/sched.c static void free_fair_sched_group(struct · line 8510

Quoted 10 lines
kernel/sched.c +3 -0
               init_tg_cfs_entry(&root_task_group, &rq->cfs, NULL, i, NULL);
  #endif /* CONFIG_FAIR_GROUP_SCHED */
 
@@ -8415,6 +8505,10 @@ static void free_fair_sched_group(struct
  {
       int i;
 
+#ifdef CONFIG_CFS_BANDWIDTH
+     destroy_cfs_bandwidth(&tg->cfs_bandwidth);
+#endif

and here

kernel/sched.c int alloc_fair_sched_group(struct task_g · line 8542

Quoted 12 lines
kernel/sched.c +4 -1
       for_each_possible_cpu(i) {
               if (tg->cfs_rq)
                       kfree(tg->cfs_rq[i]);
@@ -8442,7 +8536,10 @@ int alloc_fair_sched_group(struct task_g
               goto err;
 
       tg->shares = NICE_0_LOAD;
-
+#ifdef CONFIG_CFS_BANDWIDTH
+     init_cfs_bandwidth(&tg->cfs_bandwidth, RUNTIME_INF,
+                     sched_cfs_bandwidth_period);
+#endif

and here

Quoted 36 lines
kernel/sched.c +28 -0
       for_each_possible_cpu(i) {
               rq = cpu_rq(i);
 
@@ -9107,6 +9204,116 @@ static u64 cpu_shares_read_u64(struct cg
 
       return (u64) tg->shares;
  }
+
+#ifdef CONFIG_CFS_BANDWIDTH
+static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
+{
+     int i;
+     static DEFINE_MUTEX(mutex);
+
+     if (tg == &root_task_group)
+             return -EINVAL;
+
+     if (!period)
+             return -EINVAL;
+
+     /*
+      * Ensure we have at least one tick of bandwidth every period.  This is
+      * to prevent reaching a state of large arrears when throttled via
+      * entity_tick() resulting in prolonged exit starvation.
+      */
+     if (NS_TO_JIFFIES(quota) < 1)
+             return -EINVAL;
+
+     mutex_lock(&mutex);
+     raw_spin_lock_irq(&tg->cfs_bandwidth.lock);
+     tg->cfs_bandwidth.period = ns_to_ktime(period);
+     tg->cfs_bandwidth.runtime = tg->cfs_bandwidth.quota = quota;
+     raw_spin_unlock_irq(&tg->cfs_bandwidth.lock);
+
+     for_each_possible_cpu(i) {
Quoted 9 lines

kernel/sched.c static u64 cpu_shares_read_u64(struct cg · line 9240

Quoted 6 lines
kernel/sched.c +6 -0
+             struct cfs_rq *cfs_rq = tg->cfs_rq[i];
+             struct rq *rq = rq_of(cfs_rq);
+
+             raw_spin_lock_irq(&rq->lock);
+             init_cfs_rq_quota(cfs_rq);
+             raw_spin_unlock_irq(&rq->lock);

Any particular reason you didn't mirror rt_rq->rt_runtime_lock?

Missed this in original reply -- just that no additional locking is required so we can avoid the overhead. The existing rq->lock synchronization against cfs_rq is sufficient.

Quoted 43 lines
Quoted 28 lines
kernel/sched.c +5 -0
+     }
+     mutex_unlock(&mutex);
+
+     return 0;
+}
 
 

Index: tip/kernel/sched_fair.c
===================================================================

kernel/sched_fair.c +9 -0
@@ -88,6 +88,15 @@ const_debug unsigned int sysctl_sched_mi
   */
  unsigned int __read_mostly sysctl_sched_shares_window = 10000000UL;
 
+
+#ifdef CONFIG_CFS_BANDWIDTH
+/*
+ * default period for cfs group bandwidth.
+ * default: 0.5s, units: nanoseconds
+ */
+static u64 sched_cfs_bandwidth_period = 500000000ULL;
+#endif
+
  static const struct sched_class fair_sched_class;
 
  /**************************************************************

kernel/sched_fair.c static void __enqueue_entity(struct cfs_ · line 412

Quoted 7 lines
kernel/sched_fair.c +3 -0
@@ -397,6 +406,9 @@ static void __enqueue_entity(struct cfs_
 
       rb_link_node(&se->run_node, parent, link);
       rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
+#ifdef CONFIG_CFS_BANDWIDTH
+     start_cfs_bandwidth(&cfs_rq->tg->cfs_bandwidth);
+#endif
  }

This really needs to life elsewhere, __*_entity() functions are for rb-tree muck.

Quoted 1 line
kernel/sched_fair.c +0 -0
  static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
#39 lore raw

Re: [CFS Bandwidth Control v4 4/7] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh

In reply to Peter Zijlstra

Oops missed this one before:

Quoted 17 lines · Peter Zijlstra

kernel/sched_fair.c out_throttled: · line 1532

Quoted 10 lines · Paul Turner
kernel/sched_fair.c +10 -0
+static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+     struct rq *rq = rq_of(cfs_rq);
+     struct sched_entity *se;
+
+     se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+     update_rq_clock(rq);
+     /* (Try to) avoid maintaining share statistics for idle time */
+     cfs_rq->load_stamp = cfs_rq->load_last = rq->clock_task;

Ok, so here you try to compensate for some of the weirdness from the previous patch.. wouldn't it be much saner to fully consider the throttled things dequeued for the load calculation etc.?

That's attempted -- but there's no to control wakeups which will trigger the usual updates so we do have to do something.

The alternative is more invasive re-ordering of the dequeue/enqueue paths which I think actually ends up pretty ugly without improving things.

Quoted 5 lines
Quoted 5 lines

+
+     cfs_rq->throttled = 0;
+     for_each_sched_entity(se) {
+             if (se->on_rq)
+                     break;

Quoted 9 lines
Quoted 5 lines

+
+             cfs_rq = cfs_rq_of(se);
+             enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
+             if (cfs_rq_throttled(cfs_rq))
+                     break;

That's just weird, it was throttled, you enqueued it but find it throttled.

Two reasons:

a) We might be unthrottling a child in a throttled hierarchy. This can occur regardless of conformancy (e.g. different periods)
b) edge case: suppose there's no bandwidth already and the enqueue pushes things back into a throttled state.

Quoted 5 lines
Quoted 3 lines

+     }
+
+     /* determine whether we need to wake up potentally idle cpu */

SP: potentially, also isn't there a determiner missing?

Spelling fixed, I think the determiner is ok though:

- We know nr_running must have been zero before since rq->curr == rq->idle, (also if this *has* changed then there's already a resched for that in flight and we don't need to. This also implies that rq->cfs.nr_running was == 0.

- Root cfs_rq.nr_running now being greater than zero tells us that our unthrottle was root visible (specifically, it was not a throttled child of another throttled hierachy) which tells us that there's a task waiting.

Am I missing a case?

Quoted 29 lines
Quoted 13 lines

+     if (rq->curr == rq->idle && rq->cfs.nr_running)
+             resched_task(rq->curr);

(quoted diff) +2 -0
+}
+

 static void account_cfs_rq_quota(struct cfs_rq *cfs_rq, unsigned long delta_exec)
 {

kernel/sched_fair.c +0 -1
@@ -1535,8 +1569,46 @@ static void account_cfs_rq_quota(struct
 
  static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun)
  {
-     return 1;

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1581

Quoted 10 lines
kernel/sched_fair.c +10 -0
+     int i, idle = 1;
+     u64 delta;
+     const struct cpumask *span;
+
+     if (cfs_b->quota == RUNTIME_INF)
+             return 1;
+
+     /* reset group quota */
+     raw_spin_lock(&cfs_b->lock);
+     cfs_b->runtime = cfs_b->quota;

Shouldn't that be something like:

cfs_b->runtime =
  min(cfs_b->runtime + overrun * cfs_b->quota, cfs_b->quota);

Quoted 6 lines

afaict runtime can go negative in which case we need to compensate for that, but we cannot ever get more than quota because we allow for overcommit, so not limiting things would allow us to accrue an unlimited amount of runtime.

Or can only the per-cpu quota muck go negative?

The over-run can only occur on a local cpu (e.g. due to us being unable to immediately evict a throttled entity). By injecting a constant amount of bandwidth into the global pool we are able to correct that over-run in the subsequent period.

Quoted 4 lines

In that case it should
probably be propagated back into the global bw on throttle, otherwise you can get deficits on CPUs that remain unused for a while.

I think you mean surplus :). Yes there is potentially a small amount of surplus quota in the system, the "hard" bound is that across N periods you can receive [N periods + (slice size * NR_CPUs)] quota, since this is what may be outstanding as above surpluses. Since the slice size is fairly small this over-run is also fairly tight to the stated bounds (as well as being manageable through the slice size sysctl when required).

Quoted 14 lines
Quoted 14 lines
kernel/sched_fair.c +14 -0
+     raw_spin_unlock(&cfs_b->lock);
+
+     span = sched_bw_period_mask();
+     for_each_cpu(i, span) {
+             struct rq *rq = cpu_rq(i);
+             struct cfs_rq *cfs_rq = cfs_bandwidth_cfs_rq(cfs_b, i);
+
+             if (cfs_rq->nr_running)
+                     idle = 0;
+
+             if (!cfs_rq_throttled(cfs_rq))
+                     continue;
+
+             delta = tg_request_cfs_quota(cfs_rq->tg);
Quoted 9 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1601

Quoted 6 lines
kernel/sched_fair.c +6 -0
+
+             if (delta) {
+                     raw_spin_lock(&rq->lock);
+                     cfs_rq->quota_assigned += delta;
+
+                     /* avoid race with tg_set_cfs_bandwidth */

*what* race, and *how*

When a user sets a new bandwidth limit for the cgroup (e.g. removes it, sets unlimited bandwidth). That process may in itself unthrottle the group. Since we synchronize on rq->lock, rechecking this condition is sufficient to avoid a double unthrottle here.

Quoted 10 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1610

Quoted 9 lines
kernel/sched_fair.c +8 -0
+                     if (cfs_rq_throttled(cfs_rq) &&
+                          cfs_rq->quota_used < cfs_rq->quota_assigned)
+                             unthrottle_cfs_rq(cfs_rq);
+                     raw_spin_unlock(&rq->lock);
+             }
+     }
+
+     return idle;
  }
Quoted 4 lines

This whole positive quota muck makes my head hurt, whatever did you do that for? Also it doesn't deal with wrapping, which admittedly won't really happen but still.

Ah-ha! In going through and swapping things to a single counter I remember the reason now:

It's that since we can overflow usage on the per-cpu tracking, in using a single counter care must be taken to avoid collision with RUNTIME_INF since it's (-1).

Now I'm debating whether the ugliness of these checks is worth it. Perhaps moving RUNTIME_INF out of quota_remaining and having a separate per-cpu quota enabled indicator would be the cleanest of all three.

Quoted 3 lines
#26 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Paul Turner
Quoted 65 lines · Paul Turner
Quoted 17 lines · Bharata B Rao
Quoted 16 lines · Paul Turner
Quoted 14 lines · Peter Zijlstra

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 9 lines · Paul Turner

+     update_cfs_load(cfs_rq, 0);

kernel/sched_fair.c +8 -0
+
+     /* prevent previous buddy nominations from re-picking this se */
+     clear_buddies(cfs_rq_of(se), se);
+
+     /*
+      * It's possible for the current task to block and re-wake before task
+      * switch, leading to a throttle within enqueue_task->update_curr()
+      * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

Quoted 8 lines
Quoted 2 lines

I'm not sure the example Bharata gave is correct -- I'm going to treat that discussion separately as it's not the intent here.

Just for the record, my examples were not given for the above question from Peter.

I answered two questions and I am tempted to stand by those until proven wrong :)

This is important to get right, I'm happy to elaborate.

Quoted 2 lines

1. Why do we have cfs_rq_throtted() check in dequeue_task_fair() ?

The check is primarily needed because we could become throttled as part of a regular dequeue. At which point we bail because the parent dequeue is actually complete.

(Were it necessitated by load balance we could actually not do this and just perform a hierarchal check within load_balance_fair)

Quoted 2 lines

( => How could we be running if our parent was throttled ?)

The only way we can be running if our parent was throttled is if /we/ triggered that throttle and have been marked for re-schedule.

Quoted 10 lines

Consider the following hierarchy.

Root Group
  |
  |
Group 1 (Bandwidth constrained group)
  |
  |
Group 2 (Infinite runtime group)

Quoted 6 lines

Assume both the groups have tasks in them.

When Group 1 is throttled, its cfs_rq is marked throttled, and is removed from Root group's runqueue. But leaf tasks in Group 2 continue to be enqueued in Group 1's runqueue.

Yes, the hierarchy state is maintained in isolation.

Quoted 8 lines
Quoted 5 lines

Load balancer kicks in on CPU A and figures out that it can pull a few tasks from CPU B (busiest_cpu). It iterates through all the task groups (load_balance_fair) and considers Group 2 also. It tries to pull a task from CPU B's cfs_rq for Group 2. I don't see anything that would prevent the load balancer from bailing out here.

Per above, the descendants of a throttled group are also identified (and appropriately skipped) using h_load.

This bit is still unclear to me. We do nothing in tg_load_down() to treat throttled cfs_rqs differently when calculating h_load. Nor do we do anything in load_balance_fair() to explicitly identify descendents of throttled group using h_load AFAICS. All we have is cfs_rq_throttled() check, which I think should be converted to entity_on_rq() to check for the throttled hierarchy and discard pulling from throttled hierarchies.

Regards,
Bharata.

#27 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

Quoted 72 lines · Bharata B Rao
Quoted 71 lines · Paul Turner
Quoted 17 lines · Bharata B Rao
Quoted 16 lines · Paul Turner
Quoted 14 lines · Peter Zijlstra

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 9 lines · Paul Turner

+     update_cfs_load(cfs_rq, 0);

kernel/sched_fair.c +8 -0
+
+     /* prevent previous buddy nominations from re-picking this se */
+     clear_buddies(cfs_rq_of(se), se);
+
+     /*
+      * It's possible for the current task to block and re-wake before task
+      * switch, leading to a throttle within enqueue_task->update_curr()
+      * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

Quoted 8 lines
Quoted 2 lines

I'm not sure the example Bharata gave is correct -- I'm going to treat that discussion separately as it's not the intent here.

Just for the record, my examples were not given for the above question from Peter.

I answered two questions and I am tempted to stand by those until proven wrong :)

This is important to get right, I'm happy to elaborate.

Quoted 2 lines

1. Why do we have cfs_rq_throtted() check in dequeue_task_fair() ?

The check is primarily needed because we could become throttled as part of a regular dequeue.  At which point we bail because the parent dequeue is actually complete.

(Were it necessitated by load balance we could actually not do this and just perform a hierarchal check within load_balance_fair)

Quoted 2 lines

( => How could we be running if our parent was throttled ?)

The only way we can be running if our parent was throttled is if /we/ triggered that throttle and have been marked for re-schedule.

Quoted 10 lines

Consider the following hierarchy.

Root Group
  |
  |
Group 1 (Bandwidth constrained group)
  |
  |
Group 2 (Infinite runtime group)

Quoted 6 lines

Assume both the groups have tasks in them.

When Group 1 is throttled, its cfs_rq is marked throttled, and is removed from Root group's runqueue. But leaf tasks in Group 2 continue to be enqueued in Group 1's runqueue.

Yes, the hierarchy state is maintained in isolation.

Quoted 5 lines

Load balancer kicks in on CPU A and figures out that it can pull a few tasks from CPU B (busiest_cpu). It iterates through all the task groups (load_balance_fair) and considers Group 2 also. It tries to pull a task from CPU B's cfs_rq for Group 2. I don't see anything that would prevent the load balancer from bailing out here.

Quoted 7 lines
Quoted 2 lines

Per above, the descendants of a throttled group are also identified (and appropriately skipped) using h_load.

This bit is still unclear to me. We do nothing in tg_load_down() to treat throttled cfs_rqs differently when calculating h_load.

From above:

"I agree. We ensure this does not happen by making the h_load zero. Something I thought I was doing but apparently not, will fix in repost."

Quoted 10 lines

Nor do we do
anything in load_balance_fair() to explicitly identify descendents of throttled group using h_load AFAICS. All we have is cfs_rq_throttled() check, which I think should be converted to entity_on_rq() to check for the throttled hierarchy and discard pulling from throttled hierarchies.

Regards,
Bharata.

#28 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Paul Turner
Quoted 18 lines · Paul Turner
Quoted 12 lines
Quoted 12 lines
kernel/sched_fair.c +5 -1
@@ -761,7 +788,11 @@ static void update_cfs_load(struct cfs_r
      u64 now, delta;
      unsigned long load = cfs_rq->load.weight;
 
-     if (cfs_rq->tg == &root_task_group)
+     /*
+      * Don't maintain averages for the root task group, or while we are
+      * throttled.
+      */
+     if (cfs_rq->tg == &root_task_group || cfs_rq_throttled(cfs_rq))
              return;
 
Quoted 5 lines

kernel/sched_fair.c static void update_cfs_load(struct cfs_r · line 798

Quoted 1 line
kernel/sched_fair.c +0 -0
      now = rq_of(cfs_rq)->clock_task;

Placing the return there avoids updating the timestamps, so once we get unthrottled we'll observe a very long period and skew the load avg?

Quoted 7 lines

It's easier to avoid this by fixing up the load average on unthrottle, since there's no point in moving up the intermediate timestamps on each throttled update.

The one "gotcha" in either case is that it's possible for time to drift on the child of a throttled group and I don't see an easy way around this.

drift how? running while being throttled due to non-preempt and other things?

Quoted 10 lines
Quoted 3 lines

Ideally we'd never call this on throttled groups to begin with and handle them like full dequeue/enqueue like things.

This is what is attempted -- however it's still possible actions such as wakeup which may still occur against throttled groups regardless of their queue state.

In this case we still need to preserve the correct child hierarchy state so that it can be re-enqueued when there is again bandwidth.

If wakeup is the one sore spot, why not terminate the hierarchy iteration in enqueue_task_fair that does all the load bits?

Quoted 33 lines
Quoted 19 lines
Quoted 19 lines
kernel/sched_fair.c +8 -0
@@ -1015,6 +1046,14 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
       * Update run-time statistics of the 'current'.
       */
      update_curr(cfs_rq);
+
+
+#ifdef CONFIG_CFS_BANDWIDTH
+     if (!entity_is_task(se) && (cfs_rq_throttled(group_cfs_rq(se)) ||
+          !group_cfs_rq(se)->nr_running))
+             return;
+#endif
+
      update_cfs_load(cfs_rq, 0);
      account_entity_enqueue(cfs_rq, se);
      update_cfs_shares(cfs_rq);
@@ -1087,6 +1126,11 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
       */
      update_curr(cfs_rq);
 
Quoted 13 lines

kernel/sched_fair.c dequeue_entity(struct cfs_rq *cfs_rq, st · line 1136

Quoted 8 lines
kernel/sched_fair.c +5 -0
+#ifdef CONFIG_CFS_BANDWIDTH
+     if (!entity_is_task(se) && cfs_rq_throttled(group_cfs_rq(se)))
+             return;
+#endif
+
      update_stats_dequeue(cfs_rq, se);
      if (flags & DEQUEUE_SLEEP) {
 #ifdef CONFIG_SCHEDSTATS

These make me very nervous, on enqueue you bail after adding min_vruntime to ->vruntime and calling update_curr(), but on dequeue you bail before subtracting min_vruntime from ->vruntime.

Quoted 3 lines

min_vruntime shouldn't be added in enqueue since unthrottling is treated as a wakeup (which results in placement versus min as opposed to normalization).

Sure, but at least put a comment there, I mean that's a glaring asymmetry.

Quoted 28 lines
Quoted 14 lines
Quoted 14 lines
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct
                      break;
              cfs_rq = cfs_rq_of(se);
              enqueue_entity(cfs_rq, se, flags);
+             /* don't continue to enqueue if our parent is throttled */
+             if (cfs_rq_throttled(cfs_rq))
+                     break;
              flags = ENQUEUE_WAKEUP;
      }
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq
              cfs_rq = cfs_rq_of(se);
              dequeue_entity(cfs_rq, se, flags);
 
Quoted 13 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1447

Quoted 10 lines
kernel/sched_fair.c +5 -2
-             /* Don't dequeue parent if it has other entities besides us */
-             if (cfs_rq->load.weight)
+             /*
+              * Don't dequeue parent if it has other entities besides us,
+              * or if it is throttled
+              */
+             if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
                      break;
              flags |= DEQUEUE_SLEEP;
      }

How could we even be running if our parent was throttled?

Quoted 4 lines

It's possible we throttled within the preceding dequeue_entity -- the partial update_curr against cfs_rq might be just enough to push it over the edge. In which case that entity has already been dequeued and we want to bail out.

right.

Quoted 43 lines
Quoted 15 lines
Quoted 15 lines
kernel/sched_fair.c +10 -0
@@ -1430,6 +1480,42 @@ static u64 tg_request_cfs_quota(struct t
      return delta;
 }
 
+static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+     struct sched_entity *se;
+
+     se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+     /* account load preceeding throttle */
+     update_cfs_load(cfs_rq, 0);
+
+     /* prevent previous buddy nominations from re-picking this se */
Quoted 9 lines

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 6 lines
kernel/sched_fair.c +6 -0
+     clear_buddies(cfs_rq_of(se), se);
+
+     /*
+      * It's possible for the current task to block and re-wake before task
+      * switch, leading to a throttle within enqueue_task->update_curr()
+      * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

I'm not sure the example Bharata gave is correct -- I'm going to treat that discussion separately as it's not the intent here.

Here the task _is_ running.

Specifically:

- Suppose the current task on a cfs_rq blocks
- Accordingly we issue dequeue against that task (however it remains as curr until the put)
- Before we get to the put some other activity (e.g. network bottom half) gets to run and re-wake the task
- The time elapsed for this is charged to the task, which might push it over its reservation, it then gets throttled while we're trying to queue it

BUT

Quoted 7 lines

We haven't actually done any of the enqueue work yet so there's nothing to do to take it off rq. So what we just mark it throttled and make sure that the rest of the enqueue work gets short circuited.

The clock_task helps reduce the occurrence of this since the task will be spared the majority of the SI time but it's still possible to push it over.

Ah, uhm, so this is all due to us dropping rq->lock after dequeue, right? Would

https://lkml.org/lkml/2011/1/4/228

help here?

Quoted 35 lines
Quoted 26 lines
Quoted 26 lines
kernel/sched_fair.c +19 -0
+      * In this case, since we haven't actually done the enqueue yet, cut
+      * out and allow enqueue_entity() to short-circuit
+      */
+     if (!se->on_rq)
+             goto out_throttled;
+
+     for_each_sched_entity(se) {
+             struct cfs_rq *cfs_rq = cfs_rq_of(se);
+
+             dequeue_entity(cfs_rq, se, 1);
+             if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
+                     break;
+     }
+
+out_throttled:
+     cfs_rq->throttled = 1;
+     update_cfs_rq_load_contribution(cfs_rq, 1);
+}
+
 static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
              unsigned long delta_exec)
 {
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct
 
      cfs_rq->quota_used += delta_exec;
 
Quoted 8 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 4 lines
kernel/sched_fair.c +2 -1
-     if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+     if (cfs_rq_throttled(cfs_rq) ||
+             cfs_rq->quota_used < cfs_rq->quota_assigned)
              return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

Quoted 8 lines

No -- this is just the fact that there are cases where reschedule can't evict the task immediately.

e.g. softirq or any kernel time without config_preempt

Once we're throttled we know there's no time left or point in trying to acquire it so just short circuit these until we get to a point where this task can be removed from rq.

Right, but like I argued in another email, it could be refreshed on another cpu and you now miss it.. :-)

Quoted 9 lines
Quoted 5 lines

kernel/sched_fair.c static void check_preempt_wakeup(struct · line 2040

Quoted 3 lines
kernel/sched_fair.c +3 -0
+     if (!entity_on_rq(pse))
+             return;
+#endif

Ideally that #ifdef'ery would go away too.

This can 100% go away (and is already in the #ifdefs), but it will always be true in the !BANDWIDTH case, so it's a micro-overhead. Accompanying micro-optimization isn't really needed :)

Wouldn't gcc be able to optimize if (!true) stmt; with DCE ?

#29 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

Quoted 24 lines · Peter Zijlstra
Quoted 22 lines · Paul Turner
Quoted 12 lines
Quoted 12 lines
kernel/sched_fair.c +5 -1
@@ -761,7 +788,11 @@ static void update_cfs_load(struct cfs_r
       u64 now, delta;
       unsigned long load = cfs_rq->load.weight;
 
-     if (cfs_rq->tg == &root_task_group)
+     /*
+      * Don't maintain averages for the root task group, or while we are
+      * throttled.
+      */
+     if (cfs_rq->tg == &root_task_group || cfs_rq_throttled(cfs_rq))
               return;
 
Quoted 5 lines

kernel/sched_fair.c static void update_cfs_load(struct cfs_r · line 798

Quoted 1 line
kernel/sched_fair.c +0 -0
       now = rq_of(cfs_rq)->clock_task;

Placing the return there avoids updating the timestamps, so once we get unthrottled we'll observe a very long period and skew the load avg?

It's easier to avoid this by fixing up the load average on unthrottle, since there's no point in moving up the intermediate timestamps on each throttled update.

Quoted 7 lines
Quoted 3 lines

The one "gotcha" in either case is that it's possible for time to drift on the child of a throttled group and I don't see an easy way around this.

drift how? running while being throttled due to non-preempt and other things?

Not quite -- that time will actually be omitted since we nuke the last_update on unthrottle.

What I was referring to here is that it's not easy (and not currently done) to freeze the load average clock for descendants of a throttled entity.

Plugging this properly is actually rather annoying since we'd have to do a tree walk at both throttle and unthrottle (it's not sufficient to just fix things up at unthrottle because wakeups can lead to updates in the interim, meaning we'd need to mark some state).

Whether this drift is worth all that hassle is questionable at this point.

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines

Ideally we'd never call this on throttled groups to begin with and handle them like full dequeue/enqueue like things.

This is what is attempted -- however it's still possible actions such as wakeup which may still occur against throttled groups regardless of their queue state.

Quoted 6 lines
Quoted 2 lines

In this case we still need to preserve the correct child hierarchy state so that it can be re-enqueued when there is again bandwidth.

If wakeup is the one sore spot, why not terminate the hierarchy iteration in enqueue_task_fair that does all the load bits?

It does actually terminate early already, the problem here is the processing for children has already occurred since it's a bottom up enqueue.

Perhaps this can be simplified:

If we do a single walk at the start to validate whether the entity is throttled (we can use entity_on_rq to keep things clean) then we can pass a flag into enqueue_entity indicating whether it is part of a throttled hierarchy.

This would allow us to skip the accounting and keep things accurate above without having to do all the tree walks at throttle/unthrottle.

Let me see what this looks like for the next posting.

Quoted 126 lines
Quoted 33 lines
Quoted 19 lines
Quoted 19 lines
kernel/sched_fair.c +8 -0
@@ -1015,6 +1046,14 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
        * Update run-time statistics of the 'current'.
        */
       update_curr(cfs_rq);
+
+
+#ifdef CONFIG_CFS_BANDWIDTH
+     if (!entity_is_task(se) && (cfs_rq_throttled(group_cfs_rq(se)) ||
+          !group_cfs_rq(se)->nr_running))
+             return;
+#endif
+
       update_cfs_load(cfs_rq, 0);
       account_entity_enqueue(cfs_rq, se);
       update_cfs_shares(cfs_rq);
@@ -1087,6 +1126,11 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
        */
       update_curr(cfs_rq);
 
Quoted 13 lines

kernel/sched_fair.c dequeue_entity(struct cfs_rq *cfs_rq, st · line 1136

Quoted 8 lines
kernel/sched_fair.c +5 -0
+#ifdef CONFIG_CFS_BANDWIDTH
+     if (!entity_is_task(se) && cfs_rq_throttled(group_cfs_rq(se)))
+             return;
+#endif
+
       update_stats_dequeue(cfs_rq, se);
       if (flags & DEQUEUE_SLEEP) {
  #ifdef CONFIG_SCHEDSTATS

These make me very nervous, on enqueue you bail after adding min_vruntime to ->vruntime and calling update_curr(), but on dequeue you bail before subtracting min_vruntime from ->vruntime.

Quoted 3 lines

min_vruntime shouldn't be added in enqueue since unthrottling is treated as a wakeup (which results in placement versus min as opposed to normalization).

Sure, but at least put a comment there, I mean that's a glaring asymmetry.

Quoted 28 lines
Quoted 14 lines
Quoted 14 lines
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct
                       break;
               cfs_rq = cfs_rq_of(se);
               enqueue_entity(cfs_rq, se, flags);
+             /* don't continue to enqueue if our parent is throttled */
+             if (cfs_rq_throttled(cfs_rq))
+                     break;
               flags = ENQUEUE_WAKEUP;
       }
 
@@ -1390,8 +1437,11 @@ static void dequeue_task_fair(struct rq
               cfs_rq = cfs_rq_of(se);
               dequeue_entity(cfs_rq, se, flags);
 
Quoted 13 lines

kernel/sched_fair.c static void dequeue_task_fair(struct rq · line 1447

Quoted 10 lines
kernel/sched_fair.c +5 -2
-             /* Don't dequeue parent if it has other entities besides us */
-             if (cfs_rq->load.weight)
+             /*
+              * Don't dequeue parent if it has other entities besides us,
+              * or if it is throttled
+              */
+             if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
                       break;
               flags |= DEQUEUE_SLEEP;
       }

How could we even be running if our parent was throttled?

Quoted 4 lines

It's possible we throttled within the preceding dequeue_entity -- the partial update_curr against cfs_rq might be just enough to push it over the edge.  In which case that entity has already been dequeued and we want to bail out.

right.

Quoted 43 lines
Quoted 15 lines
Quoted 15 lines
kernel/sched_fair.c +10 -0
@@ -1430,6 +1480,42 @@ static u64 tg_request_cfs_quota(struct t
       return delta;
  }
 
+static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
+{
+     struct sched_entity *se;
+
+     se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
+
+     /* account load preceeding throttle */
+     update_cfs_load(cfs_rq, 0);
+
+     /* prevent previous buddy nominations from re-picking this se */
Quoted 9 lines

kernel/sched_fair.c static u64 tg_request_cfs_quota(struct t · line 1498

Quoted 6 lines
kernel/sched_fair.c +6 -0
+     clear_buddies(cfs_rq_of(se), se);
+
+     /*
+      * It's possible for the current task to block and re-wake before task
+      * switch, leading to a throttle within enqueue_task->update_curr()
+      * versus an an entity that has not technically been enqueued yet.

I'm not quite seeing how this would happen.. care to expand on this?

I'm not sure the example Bharata gave is correct -- I'm going to treat that discussion separately as it's not the intent here.

Here the task _is_ running.

Specifically:

- Suppose the current task on a cfs_rq blocks
- Accordingly we issue dequeue against that task (however it remains as curr until the put)
- Before we get to the put some other activity (e.g. network bottom half) gets to run and re-wake the task
- The time elapsed for this is charged to the task, which might push it over its reservation, it then gets throttled while we're trying to queue it

BUT

Quoted 7 lines

We haven't actually done any of the enqueue work yet so there's nothing to do to take it off rq.  So what we just mark it throttled and make sure that the rest of the enqueue work gets short circuited.

The clock_task helps reduce the occurrence of this since the task will be spared the majority of the SI time but it's still possible to push it over.

Quoted 7 lines

Ah, uhm, so this is all due to us dropping rq->lock after dequeue, right? Would

 https://lkml.org/lkml/2011/1/4/228

help here?

omm at a glance, it'll still be cfs_rq->curr until we actually issue the put.

I don't think we can skip update_curr in the !p->on_rq case since for the non-preempt kernel case we should be counting that time; so I think this case would unfortunately still exist.

Quoted 38 lines
Quoted 38 lines
Quoted 26 lines
Quoted 26 lines
kernel/sched_fair.c +19 -0
+      * In this case, since we haven't actually done the enqueue yet, cut
+      * out and allow enqueue_entity() to short-circuit
+      */
+     if (!se->on_rq)
+             goto out_throttled;
+
+     for_each_sched_entity(se) {
+             struct cfs_rq *cfs_rq = cfs_rq_of(se);
+
+             dequeue_entity(cfs_rq, se, 1);
+             if (cfs_rq->load.weight || cfs_rq_throttled(cfs_rq))
+                     break;
+     }
+
+out_throttled:
+     cfs_rq->throttled = 1;
+     update_cfs_rq_load_contribution(cfs_rq, 1);
+}
+
  static void account_cfs_rq_quota(struct cfs_rq *cfs_rq,
               unsigned long delta_exec)
  {
@@ -1438,10 +1524,16 @@ static void account_cfs_rq_quota(struct
 
       cfs_rq->quota_used += delta_exec;
 
Quoted 8 lines

kernel/sched_fair.c static void account_cfs_rq_quota(struct · line 1529

Quoted 4 lines
kernel/sched_fair.c +2 -1
-     if (cfs_rq->quota_used < cfs_rq->quota_assigned)
+     if (cfs_rq_throttled(cfs_rq) ||
+             cfs_rq->quota_used < cfs_rq->quota_assigned)
               return;

So we are throttled but running anyway, I suppose this comes from the PI ceiling muck?

No -- this is just the fact that there are cases where reschedule can't evict the task immediately.

Quoted 9 lines
Quoted 5 lines

e.g. softirq or any kernel time without config_preempt

Once we're throttled we know there's no time left or point in trying to acquire it so just short circuit these until we get to a point where this task can be removed from rq.

Right, but like I argued in another email, it could be refreshed on another cpu and you now miss it.. :-)

Yes, that would be non-desirable.. hum, synchronizing the check under rq->lock in do_sched_cfs_period_timer() should cover this.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
kernel/sched_fair.c +3 -0
+     if (!entity_on_rq(pse))
+             return;
+#endif
Quoted 8 lines
Quoted 5 lines
Quoted 1 line

Ideally that #ifdef'ery would go away too.

This can 100% go away (and is already in the #ifdefs), but it will always be true in the !BANDWIDTH case, so it's a micro-overhead. Accompanying micro-optimization isn't really needed :)

Wouldn't gcc be able to optimize if (!true) stmt; with DCE ?

it's p->on_rq so it's a memory ref, I don't think the gcc can reduce it since the path from ttwu -> check_preempt goes through a function pointer.

although if it can handle that bifurcation then I'm super impressed :) -- ill check against the disassembly.

#30 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

In reply to Paul Turner

Hi Paul,

Quoted 17 lines · Paul Turner
kernel/sched_fair.c +8 -0
@@ -1015,6 +1046,14 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
 	 * Update run-time statistics of the 'current'.
 	 */
 	update_curr(cfs_rq);
+
+
+#ifdef CONFIG_CFS_BANDWIDTH
+	if (!entity_is_task(se) && (cfs_rq_throttled(group_cfs_rq(se)) ||
+	     !group_cfs_rq(se)->nr_running))
+		return;
+#endif
+
 	update_cfs_load(cfs_rq, 0);
 	account_entity_enqueue(cfs_rq, se);
 	update_cfs_shares(cfs_rq);

kernel/sched_fair.c enqueue_task_fair(struct rq *rq, struct · line 1412

Quoted 6 lines
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct 
 			break;
 		cfs_rq = cfs_rq_of(se);
 		enqueue_entity(cfs_rq, se, flags);
+		/* don't continue to enqueue if our parent is throttled */
+		if (cfs_rq_throttled(cfs_rq))
+			break;

1. This check (in enqueue_task_fair) ensures that if the cfs_rq we just enqueued se to is throttled, we bail our from futher enqueueing of the hierarchy.

2. In enqueue_entity() we check if the entity we are enqueing owns a throttled hieararchy and refuse to enqueue if true. And we silently refuse but continue with futher enqueue attempts.

I see that 1 can happen when there a task belonging to a throttled group wakes up.

Can you pls explain the scenario when 2 is needed ?

Regards,
Bharata.

#31 lore raw

Re: [CFS Bandwidth Control v4 3/7] sched: throttle cfs_rq entities which exceed their local quota

Quoted 30 lines · Bharata B Rao

Hi Paul,

Quoted 17 lines · Paul Turner
kernel/sched_fair.c +8 -0
@@ -1015,6 +1046,14 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
        * Update run-time statistics of the 'current'.
        */
       update_curr(cfs_rq);
+
+
+#ifdef CONFIG_CFS_BANDWIDTH
+     if (!entity_is_task(se) && (cfs_rq_throttled(group_cfs_rq(se)) ||
+          !group_cfs_rq(se)->nr_running))
+             return;
+#endif
+
       update_cfs_load(cfs_rq, 0);
       account_entity_enqueue(cfs_rq, se);
       update_cfs_shares(cfs_rq);

kernel/sched_fair.c enqueue_task_fair(struct rq *rq, struct · line 1412

Quoted 6 lines
kernel/sched_fair.c +3 -0
@@ -1363,6 +1407,9 @@ enqueue_task_fair(struct rq *rq, struct
                       break;
               cfs_rq = cfs_rq_of(se);
               enqueue_entity(cfs_rq, se, flags);
+             /* don't continue to enqueue if our parent is throttled */
+             if (cfs_rq_throttled(cfs_rq))
+                     break;

1. This check (in enqueue_task_fair) ensures that if the cfs_rq we just enqueued se to is throttled, we bail our from futher enqueueing of the hierarchy.

Quoted 9 lines

2. In enqueue_entity() we check if the entity we are enqueing owns a throttled hieararchy and refuse to enqueue if true. And we silently refuse but continue with futher enqueue attempts.

I see that 1 can happen when there a task belonging to a throttled group wakes up.

Can you pls explain the scenario when 2 is needed ?

As I recall this was for entity reweight

In this case on_rq is cached and it's possible we'll tip over into a throttled state when we update_curr(). I think with reweight_entity() this may no longer be required.

In my current v5 stack I've actually reworked the throttling logic to make update_curr() non-state changing again and thus eliminated the associated checks and cases.

Quoted 3 lines

Regards,
Bharata.

#68 lore raw
In reply to jacob pan
Quoted 52 lines · jacob pan
Quoted 26 lines · On Fri, 25 Feb 2011 02:03:54 -0800 Paul Turner <[email protected]> wrote:
Quoted 24 lines · jacob pan
Quoted 9 lines · On Tue, 15 Feb 2011 19:18:31 -0800 Paul Turner <[email protected]> wrote:

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Your patches provide a very useful but slightly different feature for what we need to manage idle time in order to save power. What we need is kind of a quota/period in terms of idle time. I have been playing with your patches and noticed that when the cgroup cpu usage exceeds the quota the effect of throttling is similar to what I have been trying to do with freezer subsystem. i.e. freeze and thaw at given period and percentage runtime.
https://lkml.org/lkml/2011/2/15/314

Quoted 9 lines
Quoted 3 lines

Have you thought about adding such feature (please see detailed description in the link above) to your patches?

So reading the description it seems like rooting everything in a 'freezer' container and then setting up a quota of

(1 - frozen_percentage) * nr_cpus * frozen_period * sec_to_usec

I guess you meant frozen_percentage is less than 1, i.e. 90 is .90. my code treat 90 as 90. just a clarification.

Quoted 6 lines

on a period of

frozen_period * sec_to_usec

Would provide the same functionality. Is there other unduplicated functionality beyond this?

Do you mean the same functionality as your patch? Not really, since my approach will stop the tasks based on hard time slices. But seems your patch will allow them to run if they don't exceed the quota. Am i missing something?
That is the only functionality difference i know.

Quoted 5 lines

Like the reviewer of freezer patch pointed out, it is a more logical fit to implement such feature in scheduler/yours in stead of freezer. So i am wondering if your patch can be expended to include limiting quota on real time.

Do you mean sched rt group controller? Have you looked at cpu.rt_runtime_us and cpu.rt_perioud_us?

Quoted 8 lines

I did a comparison study between CFS BW and freezer patch on skype with identical quota setting as you pointed out earlier. Both use 2 sec period and .2 sec quota (10%). Skype typically uses 5% of the CPU on my system when placing a call(below cfs quota) and it wakes up every 100ms to do some quick checks. Then I run skype in cpu then freezer cgroup (with all its children). Here is my result based on timechart and powertop.

Quoted 5 lines

patch name wakeups skype call?
------------------------------------------------------------------
CFS BW 10/sec yes
freezer 1/sec no

Is this good or bad for CFS BW?

Signature · 2 lines
	Three Cheers,
	Balbir
#69 lore raw
Quoted 71 lines · on Tue, 8 Mar 2011 09:27:59 +0530 Balbir Singh wrote:
Quoted 52 lines · jacob pan
Quoted 26 lines · On Fri, 25 Feb 2011 02:03:54 -0800 Paul Turner <[email protected]> wrote:
Quoted 24 lines · jacob pan
Quoted 9 lines · On Tue, 15 Feb 2011 19:18:31 -0800 Paul Turner <[email protected]> wrote:

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Your patches provide a very useful but slightly different feature for what we need to manage idle time in order to save power. What we need is kind of a quota/period in terms of idle time. I have been playing with your patches and noticed that when the cgroup cpu usage exceeds the quota the effect of throttling is similar to what I have been trying to do with freezer subsystem. i.e. freeze and thaw at given period and percentage runtime.
https://lkml.org/lkml/2011/2/15/314

Quoted 9 lines
Quoted 3 lines

Have you thought about adding such feature (please see detailed description in the link above) to your patches?

So reading the description it seems like rooting everything in a 'freezer' container and then setting up a quota of

(1 - frozen_percentage) * nr_cpus * frozen_period * sec_to_usec

I guess you meant frozen_percentage is less than 1, i.e. 90 is .90. my code treat 90 as 90. just a clarification.

Quoted 6 lines

on a period of

frozen_period * sec_to_usec

Would provide the same functionality. Is there other unduplicated functionality beyond this?

Do you mean the same functionality as your patch? Not really, since my approach will stop the tasks based on hard time slices. But seems your patch will allow them to run if they don't exceed the quota. Am i missing something?
That is the only functionality difference i know.

Quoted 5 lines

Like the reviewer of freezer patch pointed out, it is a more logical fit to implement such feature in scheduler/yours in stead of freezer. So i am wondering if your patch can be expended to include limiting quota on real time.

Do you mean sched rt group controller? Have you looked at cpu.rt_runtime_us and cpu.rt_perioud_us?

Quoted 8 lines

I did a comparison study between CFS BW and freezer patch on skype with identical quota setting as you pointed out earlier. Both use 2 sec period and .2 sec quota (10%). Skype typically uses 5% of the CPU on my system when placing a call(below cfs quota) and it wakes up every 100ms to do some quick checks. Then I run skype in cpu then freezer cgroup (with all its children). Here is my result based on timechart and powertop.

Quoted 7 lines
Quoted 5 lines

patch name wakeups skype call?
------------------------------------------------------------------
CFS BW 10/sec yes
freezer 1/sec no

Is this good or bad for CFS BW?

In terms of power saving for this particular use case, it is bad for CFS BW. Since I am trying use cgroup to manage applications that are not written with power saving in mind. CFS BW does not prevent unnecessary wake-ups from these apps., therefore the system consumes more power than the case where freezer duty cycling patch is used. In my use case, as soon as skype is switched to the UI foreground, it will be moved to another cgroup where enough quota will be given to allow it place calls. Therefore, not being able to make calls while being throttled is not a concern.

For mobile devices, often have just one app in the foreground. So throttling background apps may not impact user experience but still can save power.

Since CFS BW patch has the period and quota concept on BW control, that is why I am asking if it is worth extending CFS BW patch to have a idle time quota. Perhaps adding another parameter to allow limitting the idle time in parallel to cfs_quota.

Rafael (CCed) wants to get an opinion from the scheduler folks before considering the freezer patch.

Thanks,

Jacob

#70 lore raw
In reply to jacob pan
Quoted 33 lines · jacob pan
Quoted 30 lines · On Fri, 25 Feb 2011 02:03:54 -0800 Paul Turner <[email protected]> wrote:
Quoted 27 lines · jacob pan
Quoted 9 lines · On Tue, 15 Feb 2011 19:18:31 -0800 Paul Turner <[email protected]> wrote:

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Your patches provide a very useful but slightly different feature for what we need to manage idle time in order to save power. What we need is kind of a quota/period in terms of idle time. I have been playing with your patches and noticed that when the cgroup cpu usage exceeds the quota the effect of throttling is similar to what I have been trying to do with freezer subsystem. i.e. freeze and thaw at given period and percentage runtime.
https://lkml.org/lkml/2011/2/15/314

Have you thought about adding such feature (please see detailed description in the link above) to your patches?

Quoted 13 lines
Quoted 5 lines

So reading the description it seems like rooting everything in a 'freezer' container and then setting up a quota of

(1 - frozen_percentage)  * nr_cpus * frozen_period * sec_to_usec

I guess you meant frozen_percentage is less than 1, i.e. 90 is .90. my code treat 90 as 90. just a clarification.

Quoted 6 lines

on a period of

frozen_period * sec_to_usec

Would provide the same functionality.  Is there other unduplicated functionality beyond this?

Sorry -- I was out last week; comments inline.

Quoted 5 lines

Do you mean the same functionality as your patch? Not really, since my approach will stop the tasks based on hard time slices
. But seems your
patch will allow them to run if they don't exceed the quota. Am i missing something?

Right, this is what was discussed above.

Quoted 6 lines

That is the only functionality difference i know.

Like the reviewer of freezer patch pointed out, it is a more logical fit to implement such feature in scheduler/yours in stead of freezer. So i am wondering if your patch can be expended to include limiting quota on real time.

The following two configurations should effectively exactly mirror the freezer behavior without modification.

A) background while(1) thread on each cpu within the cgroup This will result in synchronous consumption / exhaustion of quota in a manor that duplicates the periodic freezing.

Given the goal is power-saving, this is obviously non-ideal. However:

B) A userspace daemon toggles quota at the desired interval

Supposing you wanted a freezer period of 100ms per second, then having a daemon wake up at 900ms into the interval and then setting a quota amount that is effectively zero will then "freeze" the group. Said daemon can then release things by returning the group to an infinite quota in 100ms, and then sleeping for another 900ms.

Is there particular advantage of doing this in-kernel?

Quoted 9 lines

I did a comparison study between CFS BW and freezer patch on skype with identical quota setting as you pointed out earlier. Both use 2 sec period and .2 sec quota (10%). Skype typically uses 5% of the CPU on my system when placing a call(below cfs quota) and it wakes up every 100ms to do some quick checks. Then I run skype in cpu then freezer cgroup (with all its children). Here is my result based on timechart and powertop.

Quoted 5 lines

patch name      wakeups         skype call?
------------------------------------------------------------------
CFS BW          10/sec          yes
freezer         1/sec           no

Is this a true saving? While the actual task wake-up has been hidden, the cpu is still coming out of a halt/idle state and processing the interrupt/etc.

Have you had the chance to measure the actual comparative power-usage in this case?

Quoted 5 lines

Skype might not be the best example to illustrate the real usage of the feature, but we are targeting mobile device where they are mostly off or often have only one application allowed in foreground. So we want to reduce wakeups coming from the tasks that are not in the foreground.

If reducing wake-ups (at the userspace level) is proven to deliver performance improvements, then it might be more productive to approach that directly by considering strategies such as batching wakeups and processing them periodically.

This would not have the negative performance impact of the current approach, as well as being more deterministic.

Quoted 13 lines
Quoted 13 lines

One thing that does seem undesirable about your approach is (as it seems to be described) threads will not be able to take advantage of naturally occurring idle cycles and will incur a potential performance penalty even at use << frozen_percentage.

e.g. From your post

       |  |<-- 90% frozen -     ->|  |
|  | ____|  |________________x_|  |__________________|  |_____

        |<---- 5 seconds     ---->|

Quoted 8 lines
Quoted 5 lines

Suppose no threads active until the wake up at x, suppose there is an accompanying 1 second of work for that thread to do.  That execution time will be dilated to ~1.5 seconds (as it will span the 0.5 seconds the freezer will stall for).  But the true usage for this period is ~20% <<< 90%

I agree my approach does not consider the natural cycle. But I am not sure if a thread can wake up at x when FROZEN.

While the ascii is a little mailer-mangled, in the diagram above x was intended to precede the "frozen" time segment, but at a point where the work it wants to do exceeds the time-before-freeze resulting in dilation of execution and a performance regression.

#71 lore raw
Quoted 77 lines · On Wed, 9 Mar 2011 02:12:36 -0800 Paul Turner <[email protected]> wrote:
Quoted 33 lines · jacob pan
Quoted 30 lines · On Fri, 25 Feb 2011 02:03:54 -0800 Paul Turner <[email protected]> wrote:
Quoted 27 lines · jacob pan
Quoted 9 lines · On Tue, 15 Feb 2011 19:18:31 -0800 Paul Turner <[email protected]> wrote:

Hi all,

Please find attached v4 of CFS bandwidth control; while this rebase against some of the latest SCHED_NORMAL code is new, the features and methodology are fairly mature at this point and have proved both effective and stable for several workloads.

As always, all comments/feedback welcome.

Hi Paul,

Your patches provide a very useful but slightly different feature for what we need to manage idle time in order to save power. What we need is kind of a quota/period in terms of idle time. I have been playing with your patches and noticed that when the cgroup cpu usage exceeds the quota the effect of throttling is similar to what I have been trying to do with freezer subsystem. i.e. freeze and thaw at given period and percentage runtime.
https://lkml.org/lkml/2011/2/15/314

Have you thought about adding such feature (please see detailed description in the link above) to your patches?

Quoted 13 lines
Quoted 5 lines

So reading the description it seems like rooting everything in a 'freezer' container and then setting up a quota of

(1 - frozen_percentage)  * nr_cpus * frozen_period * sec_to_usec

I guess you meant frozen_percentage is less than 1, i.e. 90 is .90. my code treat 90 as 90. just a clarification.

Quoted 6 lines

on a period of

frozen_period * sec_to_usec

Would provide the same functionality.  Is there other unduplicated functionality beyond this?

Sorry -- I was out last week; comments inline.

Quoted 5 lines

Do you mean the same functionality as your patch? Not really, since my approach will stop the tasks based on hard time slices . But seems your
patch will allow them to run if they don't exceed the quota. Am i missing something?

Right, this is what was discussed above.

Quoted 6 lines

That is the only functionality difference i know.

Like the reviewer of freezer patch pointed out, it is a more logical fit to implement such feature in scheduler/yours in stead of freezer. So i am wondering if your patch can be expended to include limiting quota on real time.

The following two configurations should effectively exactly mirror the freezer behavior without modification.

A) background while(1) thread on each cpu within the cgroup This will result in synchronous consumption / exhaustion of quota in a manor that duplicates the periodic freezing.

Given the goal is power-saving, this is obviously non-ideal. However:

B) A userspace daemon toggles quota at the desired interval

Quoted 8 lines

Supposing you wanted a freezer period of 100ms per second, then having a daemon wake up at 900ms into the interval and then setting a quota amount that is effectively zero will then "freeze" the group. Said daemon can then release things by returning the group to an infinite quota in 100ms, and then sleeping for another 900ms.

Is there particular advantage of doing this in-kernel?

Yes, option B will mirror the behavior of the freezer patch. My concern is that doing this in user space will be less efficient than doing it in the kernel. For each period to run, the user daemon has to wake up twice to adjust the quota. I guess if you do idle time quota check in the kernel it may not need the extra wake-ups?
I do plan to have multiple cgroups with different period and runtime quota, so the wake-ups will add up.

Quoted 16 lines
Quoted 10 lines

I did a comparison study between CFS BW and freezer patch on skype with identical quota setting as you pointed out earlier. Both use 2 sec period and .2 sec quota (10%). Skype typically uses 5% of the CPU on my system when placing a call(below cfs quota) and it wakes up every 100ms to do some quick checks. Then I run skype in cpu then freezer cgroup (with all its children). Here is my result based on timechart and powertop.

Quoted 5 lines

patch name      wakeups         skype call?
------------------------------------------------------------------
CFS BW          10/sec          yes
freezer         1/sec           no

Quoted 4 lines

Is this a true saving? While the actual task wake-up has been hidden, the cpu is still coming out of a halt/idle state and processing the interrupt/etc.

I think it is true power saving, consider wake-ups from CPU C states are resulted from either timer or device IRQ, frozen process will directly reduce timer IRQ.

Quoted 3 lines

Have you had the chance to measure the actual comparative power-usage in this case?

I have yet to do such study, it is in my plan.

Quoted 33 lines
Quoted 6 lines

Skype might not be the best example to illustrate the real usage of the feature, but we are targeting mobile device where they are mostly off or often have only one application allowed in foreground. So we want to reduce wakeups coming from the tasks that are not in the foreground.

If reducing wake-ups (at the userspace level) is proven to deliver performance improvements, then it might be more productive to approach that directly by considering strategies such as batching wakeups and processing them periodically.

This would not have the negative performance impact of the current approach, as well as being more deterministic.

Quoted 18 lines
Quoted 18 lines

One thing that does seem undesirable about your approach is (as it seems to be described) threads will not be able to take advantage of naturally occurring idle cycles and will incur a potential performance penalty even at use << frozen_percentage.

e.g. From your post

       |  |<-- 90% frozen -     ->|  |
|  | ____|  |________________x_|  |__________________|  |_____

        |<---- 5 seconds     ---->|

Suppose no threads active until the wake up at x, suppose there is an accompanying 1 second of work for that thread to do.  That execution time will be dilated to ~1.5 seconds (as it will span the 0.5 seconds the freezer will stall for).  But the true usage for this period is ~20% <<< 90%

Quoted 8 lines
Quoted 3 lines

I agree my approach does not consider the natural cycle. But I am not sure if a thread can wake up at x when FROZEN.

While the ascii is a little mailer-mangled, in the diagram above x was intended to precede the "frozen" time segment, but at a point where the work it wants to do exceeds the time-before-freeze resulting in dilation of execution and a performance regression.

Thanks for explaining again.

Jacob