linux-kernel - Re: sched_yield: delete sysctl_sched_compat

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071127145747.5f4d0aca@laptopd505.fenrus.org>
Date:	Tue, 27 Nov 2007 14:57:47 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Cc:	mingo@...e.hu, LKML <linux-kernel@...r.kernel.org>
Subject: Re: sched_yield: delete sysctl_sched_compat_yield

On Tue, 27 Nov 2007 17:33:05 +0800
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com> wrote:

> If echo "1">/proc/sys/kernel/sched_compat_yield before starting
> volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
> my 16-core tigerton.
> 
> 1) If /proc/sys/kernel/sched_compat_yield=1, comparing with 2.6.22,
> 2.6.24-rc3 has more than 70% improvement;
> 2) If /proc/sys/kernel/sched_compat_yield=0, comparing with 2.6.22,
> 2.6.24-rc3 has more than 80% regression;
> 
> On other machines, the volanoMark result also has much improvement if
> /proc/sys/kernel/sched_compat_yield=1.
> 
> Would you like to change function yield_task_fair to delete codes
> around sysctl_sched_compat_yield, or just initiate it to 1?
> 

sounds like a bad idea; volanomark (well, technically the jvm behind
it) is abusing sched_yield() by assuming it does something it really
doesn't do, and as it happens some of the earlier 2.6 schedulers
accidentally happened to behave in a way that was nice for this
benchmark. 

Todays kernel has a different behavior somewhat (and before people
scream "regression"; sched_yield() behavior isn't really specified and
doesn't make any sense at all, whatever you get is what you get....
it's pretty much an insane defacto behavior that is incredibly tied to
which decisions the scheduler makes how, and no app can depend on that
in any way. In fact, I've proposed to make sched_yield() just do an
msleep(1)... that'd be closer to what sched_yield is supposed to do
standard wise than any of the current behaviors .... ;_

-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-
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/