linux-kernel - [RFC 60/60] cosched: Add command line argument to enable coscheduling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri,  7 Sep 2018 23:40:47 +0200
From:   Jan H. Schönherr <jschoenh@...zon.de>
To:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Jan H. Schönherr <jschoenh@...zon.de>,
        linux-kernel@...r.kernel.org
Subject: [RFC 60/60] cosched: Add command line argument to enable coscheduling

Add a new command line argument cosched_max_level=<n>, which allows
enabling coscheduling at boot. The number corresponds to the scheduling
domain up to which coscheduling can later be enabled for cgroups.

For example, to enable coscheduling of cgroups at SMT level, one would
specify cosched_max_level=1.

The use of symbolic names (like off, core, socket, system) is currently
not possible, but could be added. However, to force coscheduling at up
to system level not knowing the scheduling domain topology in advance,
it is possible to just specify a too large number. It will be clamped
transparently to system level.

Signed-off-by: Jan H. Schönherr <jschoenh@...zon.de>
---
 kernel/sched/cosched.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/cosched.c b/kernel/sched/cosched.c
index eb6a6a61521e..a1f0d3a7b02a 100644
--- a/kernel/sched/cosched.c
+++ b/kernel/sched/cosched.c
@@ -162,6 +162,29 @@ static int __init cosched_split_domains_setup(char *str)
 
 early_param("cosched_split_domains", cosched_split_domains_setup);
 
+static int __read_mostly cosched_max_level;
+
+static __init int cosched_max_level_setup(char *str)
+{
+	int val, ret;
+
+	ret = kstrtoint(str, 10, &val);
+	if (ret)
+		return ret;
+	if (val < 0)
+		val = 0;
+
+	/*
+	 * Note, that we cannot validate the upper bound here as we do not
+	 * know it yet. It will happen in cosched_init_topology().
+	 */
+
+	cosched_max_level = val;
+	return 0;
+}
+
+early_param("cosched_max_level", cosched_max_level_setup);
+
 struct sd_sdrqmask_level {
 	int groups;
 	struct cpumask **masks;
@@ -407,6 +430,10 @@ void cosched_init_topology(void)
 
 	/* Make permanent */
 	set_sched_topology(tl);
+
+	/* Adjust user preference */
+	if (cosched_max_level >= levels)
+		cosched_max_level = levels - 1;
 }
 
 /*
@@ -419,7 +446,7 @@ void cosched_init_topology(void)
  *
  * We can do this without any locks, as nothing will automatically traverse into
  * these data structures. This requires an update of the sdrq.is_root property,
- * which will happen only later.
+ * which will happen only after everything as been setup at the very end.
  */
 void cosched_init_hierarchy(void)
 {
@@ -483,6 +510,9 @@ void cosched_init_hierarchy(void)
 		sdrq->sd_parent = &sd->shared->rq.cfs.sdrq;
 		list_add_tail(&sdrq->siblings, &sdrq->sd_parent->children);
 	}
+
+	/* Activate the hierarchy according to user preferences */
+	cosched_set_scheduled(&root_task_group, cosched_max_level);
 }
 
 /*****************************************************************************
-- 
2.9.3.1.gcba166c.dirty