Re: [PATCH 2/2] sched/rt: Optimizate task_woken_rt()

From: Steven Rostedt
Date: Thu Apr 30 2015 - 22:52:04 EST


On Fri, 1 May 2015 10:02:47 +0800
pang.xunlei@xxxxxxxxxx wrote:

> > >
> > > - Remove "!test_tsk_need_resched(rq->curr)" condition, because
> > > the flag might be set right before the waking up, but we still
> > > need to push equal or lower priority tasks, it should be removed.
> > > Without this condition, we actually get the right logic.
> >
> > But doesn't that happen when we schedule?
>
> It does, but will have some latency.

What latency? The need_resched flag is set, that means as soon as this
CPU is in a preemptable situation, it will schedule. The most common
case would be return from interrupt, as interrupts or softirqs are
usually what trigger the wakeups.

But if we do it here, the need resched flag could be set because
another higher priority task is about to preempt the current one that
is higher than what just woke up. So we move it now to another CPU, and
then on return of the interrupt we schedule. Then the current running
task gets preempted by the higher priority task and it too can migrate
to the CPU we just pushed the other one to, and it still doesn't run,
but yet it got moved for no reason at all.

I feel better if the need resched flag is set, we wait till a schedule
happens to see where everything is about to be moved.


>
> Still "rq->curr->prio <= p->prio" will be enough for us to ensure the
> proper
> push_rt_tasks() without this condition.

I have no idea what the above means.

>
> Beside that, for "rq->curr->nr_cpus_allowed < 2", I noticed it was
> introduced
> by commit b3bc211cfe7d5fe94b, but with "!test_tsk_need_resched(rq->curr)",
> it actaully can't be satisfied.

What can't be satisfied?

>
> So, I think this condition should be removed.

I'm still not convinced.

-- Steve

--
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/