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]

Date:	Mon, 3 Dec 2007 09:04:04 -0800
From:	"David Schwartz" <davids@...master.com>
To:	"Nick Piggin" <nickpiggin@...oo.com.au>,
	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: RE: sched_yield: delete sysctl_sched_compat_yield


	I've asked versions of this question at least three times and never gotten
anything approaching a straight answer:

	1) What is the current default 'sched_yield' behavior?

	2) What is the current alternate 'sched_yield' behavior?

	3) Are either of them sensible? Simply acting as if the current thread's
timeslice was up should be sufficient.

	The implication I keep getting is that neither the default behavior nor the
alternate behavior are sensible. What is so hard about simply scheduling the
next thread?

	We don't need perfection, but it sounds like we have two alternatives of
which neither is sensible.

	DS


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