From: Ben Widawsky <ben@bwidawsk.net>
To: Daniel Vetter <daniel@ffwll.c>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 00/15] [RFC] Forced throttling/scheduling
Date: Mon, 2 Apr 2012 11:28:15 -0700 [thread overview]
Message-ID: <20120402112815.6cc54c77@bwidawsk.net> (raw)
In-Reply-To: <1321669472-8045-1-git-send-email-ben@bwidawsk.net>
On Fri, 18 Nov 2011 18:24:17 -0800
Ben Widawsky <ben@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?
prev parent reply other threads:[~2012-04-02 18:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-19 2:24 [PATCH 00/15] [RFC] Forced throttling/scheduling Ben Widawsky
2011-11-19 2:24 ` [PATCH 01/15] drm/i915: refactor debugfs open function Ben Widawsky
2011-11-20 18:50 ` Kenneth Graunke
2011-11-19 2:24 ` [PATCH 02/15] drm/i915: refactor debugfs create functions Ben Widawsky
2011-11-19 2:24 ` [PATCH 03/15] drm/i915: relative_constants_mode race fix Ben Widawsky
2011-11-23 22:30 ` Ben Widawsky
2011-11-19 2:24 ` [PATCH 04/15] drm/i915: drop lock support for i915_wait_request Ben Widawsky
2011-11-19 2:24 ` [PATCH 05/15] drm/i915: remove mm structure from file_priv Ben Widawsky
2011-11-19 2:24 ` [PATCH 06/15] drm/i915: Keep track of drm_file in file_priv Ben Widawsky
2011-11-19 2:24 ` [PATCH 07/15] drm/i915: Keep track of request counts Ben Widawsky
2011-11-19 2:24 ` [PATCH 08/15] drm/i915: fairness Ben Widawsky
2011-11-19 2:24 ` [PATCH 09/15] drm/i915: Keep track of open i915 clients Ben Widawsky
2011-11-19 2:24 ` [PATCH 10/15] drm/i915: debugfs entry for " Ben Widawsky
2011-11-19 2:24 ` [PATCH 11/15] drm/i915: debugfs entries for scheduler params Ben Widawsky
2011-11-19 2:24 ` [PATCH 12/15] drm/i915: infrastructure to support scheduler types Ben Widawsky
2011-11-19 2:24 ` [PATCH 13/15] drm/i915: get/set scheduler type from debugfs Ben Widawsky
2011-11-19 2:24 ` [PATCH 14/15] drm/i915: Implement batch scheduler Ben Widawsky
2011-11-19 2:24 ` [PATCH 15/15] drm/i915: Add handling for batch parameters in debugfs Ben Widawsky
2011-11-29 14:30 ` [PATCH 00/15] [RFC] Forced throttling/scheduling Eugeni Dodonov
2012-04-02 18:28 ` Ben Widawsky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120402112815.6cc54c77@bwidawsk.net \
--to=ben@bwidawsk.net \
--cc=daniel@ffwll.c \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).