lkml.org 
[lkml]   [2006]   [Jun]   [11]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    DateSun, 11 Jun 2006 07:58:28 +0200
    FromIngo Molnar <>
    SubjectRe: [RFC PATCH -rt] Priority preemption latency
    * Darren Hart <dvhltc@us.ibm.com> wrote:
    
    > Thanks for the updated patch!  It wouldn't quite build (proc_misc.c 
    > still referenced the old rt_overload_* variables, fixup patch attached 
    > removing those print statements). [...]
    
    doh, forgot to send those changes ...
    
    > [...]  I have it running on a 4 way opteron box running prio-preempt 
    > in a timed while loop, exiting only on failure.  It's been running 
    > fine for several minutes - usually fails in under a mintue.  We'll see 
    > how it's doing in the morning :-)
    
    meanwhile i've released -rt3 with the fix (and the procfs change) 
    included.
    
    i slept on it meanwhile, and i think the safest would be to also do the 
    attached patch ontop of -rt3. This makes the 'kick other CPUs' logic 
    totally unconditional - so whatever happens the wakeup code will notice 
    if an RT task is in trouble finding the right CPU. Under -rt3 we'd only 
    run into this branch if we stayed on the same CPU - but there can be 
    cases when we have your scenario even in precisely such a case. It's 
    rare but possible.
    
    	Ingo
    
    Index: linux-rt.q/kernel/sched.c
    ===================================================================
    --- linux-rt.q.orig/kernel/sched.c
    +++ linux-rt.q/kernel/sched.c
    @@ -1588,38 +1588,37 @@ out_set_cpu:
     
     		this_cpu = smp_processor_id();
     		cpu = task_cpu(p);
    -	} else {
    +	}
    +	/*
    +	 * If a newly woken up RT task cannot preempt the
    +	 * current (RT) task (on a target runqueue) then try
    +	 * to find another CPU it can preempt:
    +	 */
    +	if (rt_task(p) && !TASK_PREEMPTS_CURR(p, rq)) {
    +		this_rq = cpu_rq(this_cpu);
     		/*
    -		 * If a newly woken up RT task cannot preempt the
    -		 * current (RT) task (on a target runqueue) then try
    -		 * to find another CPU it can preempt:
    +		 * Special-case: the task on this CPU can be
    +		 * preempted. In that case there's no need to
    +		 * trigger reschedules on other CPUs, we can
    +		 * mark the current task for reschedule.
    +		 *
    +		 * (Note that it's safe to access this_rq without
    +		 * extra locking in this particular case, because
    +		 * we are on the current CPU.)
     		 */
    -		if (rt_task(p) && !TASK_PREEMPTS_CURR(p, rq)) {
    -			this_rq = cpu_rq(this_cpu);
    +		if (TASK_PREEMPTS_CURR(p, this_rq))
    +			set_tsk_need_resched(this_rq->curr);
    +		else
     			/*
    -			 * Special-case: the task on this CPU can be
    -			 * preempted. In that case there's no need to
    -			 * trigger reschedules on other CPUs, we can
    -			 * mark the current task for reschedule.
    -			 *
    -			 * (Note that it's safe to access this_rq without
    -			 * extra locking in this particular case, because
    -			 * we are on the current CPU.)
    +			 * Neither the intended target runqueue
    +			 * nor the current CPU can take this task.
    +			 * Trigger a reschedule on all other CPUs
    +			 * nevertheless, maybe one of them can take
    +			 * this task:
     			 */
    -			if (TASK_PREEMPTS_CURR(p, this_rq))
    -				set_tsk_need_resched(this_rq->curr);
    -			else
    -				/*
    -				 * Neither the intended target runqueue
    -				 * nor the current CPU can take this task.
    -				 * Trigger a reschedule on all other CPUs
    -				 * nevertheless, maybe one of them can take
    -				 * this task:
    -				 */
    -				smp_send_reschedule_allbutself();
    +			smp_send_reschedule_allbutself();
     
    -			schedstat_inc(this_rq, rto_wakeup);
    -		}
    +		schedstat_inc(this_rq, rto_wakeup);
     	}
     
     out_activate:
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    \
     
     \ /
      Last update: 2006-06-11 08:02    [from the cache]
    ©2003-2008