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  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:	Thu, 17 May 2007 18:01:11 -0700
From:	Bill Huey (hui) <>
To:	Ingo Molnar <>
	Linus Torvalds <>,
	Andrew Morton <>,
	Con Kolivas <>,
	Nick Piggin <>, Mike Galbraith <>,
	Arjan van de Ven <>,
	Peter Williams <>,
	Thomas Gleixner <>,,
	Willy Tarreau <>,
	Gene Heskett <>, Mark Lord <>,
	William Lee Irwin III <>,
	"Bill Huey (hui)" <>
Subject: Re: [patch] CFS scheduler, -v12

On Thu, May 17, 2007 at 05:18:41PM -0700, Bill Huey wrote:
> On Sun, May 13, 2007 at 05:38:53PM +0200, Ingo Molnar wrote:
> > Even a simple 3D app like glxgears does a sys_sched_yield() for every 
> > frame it generates (!) on certain 3D cards, which in essence punishes 
> > any scheduler that implements sys_sched_yield() in a sane manner. This 
> > interaction of CFS's yield implementation with this user-space bug could 
> > be the main reason why some testers reported SD to be handling 3D games 
> > better than CFS. (SD uses a yield implementation similar to the vanilla 
> > scheduler.)
> > 
> > So i've added a yield workaround to -v12, which makes it work similar to 
> > how the vanilla scheduler and SD does it. (Xorg has been notified and 
> > this bug should be fixed there too. This took some time to debug because 
> > the 3D driver i'm using for testing does not use sys_sched_yield().) The 
> > workaround is activated by default so -v12 should work 'out of the box'.
> This is an incorrect analysis. OpenGL has the ability to "yield" after
> every frame specifically for SGI IRIX (React/Pro) frame scheduler (driven
> by the system vertical retrace interrupt) so that it can free up CPU
> resources for other tasks to run. The problem here is that the yield
> behavior is treated generally instead of specifically to a particular
> proportion scheduler policy.
> The correct solution is for the app to use a directed yield and a policy
> that can directly support it so that OpenGL can guaratee a frame rate
> governed by CPU bandwidth allocated by the scheduler.
> Will is working on such a mechanism now.

Follow up:


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists