linux-kernel - Re: Regression with sched yield

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 18 Feb 2008 16:35:12 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	balbir@...ux.vnet.ibm.com
Cc:	Ingo Molnar <mingo@...e.hu>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: Regression with sched yield - 2.6.25-rc2-mm1


On Mon, 2008-02-18 at 20:49 +0530, Balbir Singh wrote:
> Peter Zijlstra wrote:
> > On Mon, 2008-02-18 at 20:18 +0530, Balbir Singh wrote:
> > 
> >>> Humm, the check that should have avoided that is:
> >>>
> >>>         /*
> >>>          * Are we the only task in the tree?
> >>>          */
> >>>         if (unlikely(rq->load.weight == curr->se.load.weight))
> >>>                 return;
> >>>

> OK, but does it belong to the cfs_rq?

I'm not looking at the cfs_rq, but at rq. Looking at cfs_rq isn't
correct because it might be a group with only a single task even though
there might be more tasks on this cpu.

Now it turns out, looking at the rq isn't correct either. At the time I
think I thought that a runnable RT task would've preempted - but that is
of course not valid under all preemption models - and racy even on
PREEMPT=y

> >>  Having said that, rightmost was indeed
> >> NULL, so I need to figure out why it was. The other question is why would a real
> >> time task be found by sched_yield_fair? 
> > 
> > Because a rt task contributes weight and would make the test above fail
> > because rt->load would be larger than expected.
> > 
> 
> I thought we were searching an RBtree for the fair group scheduler. If what you
> say is indeed true, shouldn't we check if the task is an rt task in
> sched_yield_fair() instead of the !rightmost check?

We're not actually finding a rt task. Just the presence of a runnable RT
task on this CPU skews the weights and fools my test.

rightmost returns NULL because there just isn't anybody else in the CFS
rq (note that current isn't in the tree).


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