linux-kernel - Re: [PATCH 2/2] sched/rt: Optimizate task_woken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 30 Apr 2015 22:52:04 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	pang.xunlei@....com.cn
Cc:	Juri Lelli <juri.lelli@...il.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Xunlei Pang <pang.xunlei@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Xunlei Pang <xlpang@....com>
Subject: Re: [PATCH 2/2] sched/rt: Optimizate task_woken_rt()

On Fri, 1 May 2015 10:02:47 +0800
pang.xunlei@....com.cn 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/