Re: [PATCH] sched_rt: Removes extra checking for nr_cpus_allowedwhen calling find_lowest_rq

[Steven Rostedt]

On Tue, 2010-10-19 at 13:02 +0200, Peter Zijlstra wrote:

> > Remove the check for nr_cpus_allowed of an RT task before calling
> > find_lowest_cpu() from select_task_rq_rt function. Cause
> > find_lowest_cpu checks for rt.nr_cpus_allowed of a process.
> > It would've been nice, if we make the check before calling
> > find_lowest_cpu. But its called from other places, so keep the
> > nr_cpus_allowed check into find_lowest_cpu().
> 

Yes it is redundant, but I'm wondering if we should modify
find_lowest_rq() just to short cut this case.

That is, instead of assigning all the variables on the stack, which I'm
thinking __get_cpu_var() may act like a barrier() where gcc can't
optimize. We should probably also do the following:

static int find_lowest_rq(struct task_struct *task)
{
	struct sched_domain *sd;
-	struct cpumask *lowest_mask = __get_cpu_var(local_cpu_mask);
-	int this_cpu = smp_processor_id();
-	int cpu      = task_cpu(task);
+	struct cpumask *lowest_mask;
+	int this_cpu;
+	int cpu;

	if (task->rt.nr_cpus_allowed == 1)
		return -1; /* No other targets possible */

+	lowest_mask = __get_cpu_var(local_cpu_mask);
+	this_cpu = smp_processor_id();
+	cpu = task_cpu(task;


Then removing the redundant check may not hurt anything.

-- Steve


> > Signed-off-by: Rakib Mullick <rakib.mullick@xxxxxxxxx>
> > ---
> > 
> > --- linus-rc8/kernel/sched_rt.c	2010-10-15 05:26:43.000000000 +0600
> > +++ rakib-rc8/kernel/sched_rt.c	2010-10-19 16:22:30.000000000 +0600
> > @@ -971,8 +971,7 @@ select_task_rq_rt(struct rq *rq, struct
> >  	 * that is just being woken and probably will have
> >  	 * cold cache anyway.
> >  	 */
> > -	if (unlikely(rt_task(rq->curr)) &&
> > -	    (p->rt.nr_cpus_allowed > 1)) {
> > +	if (unlikely(rt_task(rq->curr))) {
> >  		int cpu = find_lowest_rq(p);
> > 
> >  		return (cpu == -1) ? task_cpu(p) : cpu;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/