[Intel-gfx] [PATCH 00/15] [RFC] Forced throttling/scheduling

[Ben Widawsky]

On Fri, 18 Nov 2011 18:24:17 -0800
Ben Widawsky <ben at bwidawsk.net> wrote:

> This code is currently living on my personal git repo:
> git://people.freedesktop.org/~bwidawsk/drm-intel forced_throttling
> 
> Since these are RFC, I haven't spent too much time cleaning things up.
> Feel free to comment on typos, comments you feel are missing, etc. I
> also haven't spent any time running the standard kernel tests, kmemleak
> and such - I intend to do so while these are reviewed here.
> 
> There are two main "scheduler" types implemented in this patch. What I
> refer to as a fairness scheduler, and a batch scheduler. The fairness
> scheduler is currently implemented on batch granularity but that is not
> guaranteed going forward. The batch scheduler is a way to set batch
> limits per pid. Refer to the relevant patch for more details.
> 
> It is my opinion that the fairness scheduler isn't terribly interesting
> except to prevent badly written, or malicious apps. For example, a 3d
> app which queues up a ton of work but never calls glxSwapBuffer.
> 
> The batch scheduler is also somewhat uninteresting as the values it uses
> require proper tuning and will vary from system to system, and even then
> depending on what's currently running. But like the fairness one, this
> too has its applications.
> 
> Most comments and feedback are welcome.
> 

I think one of the main gripes with these patches was the need for a
process abstraction (and using debugfs instead of sysfs). With the
context patches that I'm actively working on getting into 3.5, I'm
wondering if it's worth trying to redo this on top of the context
interface?