Re: [patch] CFS scheduler, -v12

Ingo Molnar
2007-05-18T07:33:38Z

* Bill Huey <billh@gnuppy.monkey.org> 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. [...]

i'm puzzled, incorrect in specifically what way?

> [...] 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. [...]

what you say makes no sense to me. The majority of Linux 3D apps are
already driven by the vertical retrace interrupt and properly 'yield the
CPU' if they wish so, but this has nothing to do with sys_sched_yield().

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

i'm even more puzzled. I've added sched_yield_to() to CFS -v6 and it's
been part of CFS since then. I'm curious, on what mechanism is Will
working and have any patches been sent to lkml for discussion?

Ingo