Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases

[Peter Zijlstra]

On Mon, Apr 20, 2015 at 10:52:28AM -0400, Steven Rostedt wrote:
> On Mon, 20 Apr 2015 16:22:47 +0800
> Xunlei Pang <xlpang@xxxxxxx> wrote:
> 
> >  static inline void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
> >  {
> >  }
> > @@ -1506,8 +1526,21 @@ static void put_prev_task_rt(struct rq *rq, struct task_struct *p)
> >  	 * The previous task needs to be made eligible for pushing
> >  	 * if it is still active
> >  	 */
> > -	if (on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1)
> > -		enqueue_pushable_task(rq, p);
> > +	if (on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1) {
> > +		/*
> > +		 * put_prev_task_rt() is called by many functions,
> > +		 * pick_next_task_rt() is the only one may have
> > +		 * PREEMPT_ACTIVE set. So if detecting p(current
> > +		 * task) is preempted in such case, we should
> > +		 * enqueue it to the front of the pushable plist,
> > +		 * as there may be multiple tasks with the same
> > +		 * priority as p.
> 
> The above comment is very difficult to understand. Maybe something like:
> 
> 		/*
> 		 * When put_prev_task_rt() is called by
> 		 * pick_next_task_rt(), if PREEMPT_ACTIVE is set, it
> 		 * means that the current rt task is being preempted by
> 		 * a higher priority task. To maintain FIFO, it must
> 		 * stay ahead of any other task that is queued at the
> 		 * same priority.
> 		 */
> 
> -- Steve
> 
> > +		 */
> > +		if (preempt_count() & PREEMPT_ACTIVE)
> > +			enqueue_pushable_task_preempted(rq, p);
> > +		else
> > +			enqueue_pushable_task(rq, p);
> > +	}
> >  }

This looks wrong, what do you want to find? _any_ preemption? In that
case PREEMPT_ACTIVE is wrong. What you need to check is if the task is
still on the RQ or not.

If the task was put to sleep it got dequeued, if it was not dequeued, it
got preempted.

PREEMPT_ACTIVE is only ever set for forced kernel preemption, which is a
special sub case only ever triggered with CONFIG_PREEMPT=y.
--
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/