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: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/REACT_PG/sgi_html/ch04.html bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/