From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752448AbcDAQVj (ORCPT ); Fri, 1 Apr 2016 12:21:39 -0400 Received: from casper.infradead.org ([85.118.1.10]:51919 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751318AbcDAQVi (ORCPT ); Fri, 1 Apr 2016 12:21:38 -0400 Date: Fri, 1 Apr 2016 18:21:36 +0200 From: Peter Zijlstra To: xlpang@redhat.com Cc: linux-kernel@vger.kernel.org, Juri Lelli , Ingo Molnar , Steven Rostedt Subject: Re: [PATCH] sched/deadline: No need to check NULL later_mask Message-ID: <20160401162136.GM3448@twins.programming.kicks-ass.net> References: <1459509198-26543-1-git-send-email-xlpang@redhat.com> <20160401112919.GP3430@twins.programming.kicks-ass.net> <56FE66A5.9050004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FE66A5.9050004@redhat.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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;