linux-kernel - Re: [PATCH] sched/deadline: No need to check NULL later

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160401162136.GM3448@twins.programming.kicks-ass.net>
Date:	Fri, 1 Apr 2016 18:21:36 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	xlpang@...hat.com
Cc:	linux-kernel@...r.kernel.org, Juri Lelli <juri.lelli@....com>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] sched/deadline: No need to check NULL later_mask

On Fri, Apr 01, 2016 at 08:16:37PM +0800, Xunlei Pang wrote:
> On 2016/04/01 at 19:29, Peter Zijlstra wrote:
> > On Fri, Apr 01, 2016 at 07:13:18PM +0800, Xunlei Pang wrote:
> >> Unlike rt tasks, we (should) have no deadline tasks in
> >> booting phase before the mask is allocated, so we can
> >> safely remove the check.
> > Why? And have the kernel explode once it grows an early deadline task?
> >
> > Is there _any_ benefit to this?
> 
> This is a performance-critical path, it'd be better to avoid such a check.

And the changelog didn't say.. and if its an optimization you should at
least attempt numbers or instruction counts or whatnot.

> I think in the early boot stage before sched_init_smp(), it's weird to
> use a deadline task, relying on rt tasks should be enough for us.

You never know.

Something like the below should completely avoid the problem though.

It uses __initdata storage when coming up and switched to allocated data
before we bring up smp.

A similar thing could be done to RT..

In fact, both could share the mask, its a temporary mask anyhow, and I'm
pretty sure there's more such cpumasks lying about that we can merge.

Completely untested...

---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 11594230ef4d..acdc291577a0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7243,8 +7244,6 @@ void __init sched_init_smp(void)
 	sched_init_granularity();
 	free_cpumask_var(non_isolated_cpus);
 
-	init_sched_rt_class();
-	init_sched_dl_class();
 }
 #else
 void __init sched_init_smp(void)
@@ -7444,6 +7443,9 @@ void __init sched_init(void)
 		zalloc_cpumask_var(&cpu_isolated_map, GFP_NOWAIT);
 	idle_thread_set_boot_cpu();
 	set_cpu_rq_start_time();
+
+	init_sched_rt_class();
+	init_sched_dl_class();
 #endif
 	init_sched_fair_class();
 
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index affd97ec9f65..24d7dbede99e 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1273,7 +1273,8 @@ static struct task_struct *pick_earliest_pushable_dl_task(struct rq *rq, int cpu
 	return NULL;
 }
 
-static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
+static __initdata struct cpumask __local_mask;
+static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl) = &__local_mask;
 
 static int find_later_rq(struct task_struct *task)
 {
@@ -1282,10 +1283,6 @@ static int find_later_rq(struct task_struct *task)
 	int this_cpu = smp_processor_id();
 	int best_cpu, cpu = task_cpu(task);
 
-	/* Make sure the mask is initialized first */
-	if (unlikely(!later_mask))
-		return -1;
-
 	if (task->nr_cpus_allowed == 1)
 		return -1;