mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Intel-gfx@lists.freedesktop.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Zefan Li" <lizefan.x@bytedance.com>,
	"Dave Airlie" <airlied@redhat.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Rob Clark" <robdclark@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"T . J . Mercier" <tjmercier@google.com>,
	Kenny.Ho@amd.com, "Christian König" <christian.koenig@amd.com>,
	"Brian Welty" <brian.welty@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>
Subject: Re: [RFC 11/13] cgroup/drm: Introduce weight based drm cgroup control
Date: Mon, 28 Nov 2022 09:50:52 -1000	[thread overview]
Message-ID: <Y4URHHISpZaFQmj6@slm.duckdns.org> (raw)
In-Reply-To: <30f42096-3f42-594e-8ff1-c09341925518@linux.intel.com>

Hello,

On Thu, Nov 24, 2022 at 02:32:25PM +0000, Tvrtko Ursulin wrote:
> > Soft limits is a bit of misnomer and can be confused with best-effort limits
> > such as memory.high. Prolly best to not use the term.
> 
> Are you suggesting "best effort limits" or "best effort <something>"? It
> would sounds good to me if we found the right <something>. Best effort
> budget perhaps?

A more conventional name would be hierarchical weighted distribution.

> Also, when you mention scalability you are concerned about multiple tree
> walks I have per iteration? I wasn't so much worried about that, definitely
> not for the RFC, but even in general due relatively low frequency of
> scanning and a good amount of less trivial cost being outside the actual
> tree walks (drm client walks, GPU utilisation calculations, maybe more). But
> perhaps I don't have the right idea on how big cgroups hierarchies can be
> compared to number of drm clients etc.

It's just a better way doing this kind of weight based scheduling. It's
simpler, more scalable and easier to understand how things are working. The
basic idea is pretty simple - each schedulable entity gets assigned a
timestamp and whenever it consumes the target resource, its time is wound
forward by the consumption amount divided by its absolute share - e.g. if
cgroup A deserves 25% of the entire thing and it ran for 1s, its time is
wound forward by 1s / 0.25 == 4s. There's a rbtree keyed by these timestamps
and anything wanting to consume gets put on that tree and whatever is at the
head of the tree is the next thing to run.

Thanks.

-- 
tejun

  reply	other threads:[~2022-11-28 19:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 16:11 [RFC v2 00/13] DRM scheduling cgroup controller Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 01/13] drm: Replace DRM_DEBUG with drm_dbg_core in file and ioctl handling Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 02/13] drm: Track clients by tgid and not tid Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 03/13] drm: Update file owner during use Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 04/13] cgroup: Add the DRM cgroup controller Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 05/13] drm/cgroup: Track clients per owning process Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 06/13] drm/cgroup: Allow safe external access to file_priv Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 07/13] drm/cgroup: Add ability to query drm cgroup GPU time Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 08/13] drm/cgroup: Add over budget signalling callback Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 09/13] drm/cgroup: Only track clients which are providing drm_cgroup_ops Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 10/13] cgroup/drm: Client exit hook Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 11/13] cgroup/drm: Introduce weight based drm cgroup control Tvrtko Ursulin
2022-11-22 21:29   ` Tejun Heo
2022-11-24 14:32     ` Tvrtko Ursulin
2022-11-28 19:50       ` Tejun Heo [this message]
2022-11-09 16:11 ` [RFC 12/13] drm/i915: Wire up with drm controller GPU time query Tvrtko Ursulin
2022-11-09 16:11 ` [RFC 13/13] drm/i915: Implement cgroup controller over budget throttling Tvrtko Ursulin

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=Y4URHHISpZaFQmj6@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=Kenny.Ho@amd.com \
    --cc=airlied@redhat.com \
    --cc=brian.welty@intel.com \
    --cc=cgroups@vger.kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=marcheu@chromium.org \
    --cc=robdclark@chromium.org \
    --cc=tjmercier@google.com \
    --cc=tvrtko.ursulin@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    /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

all inboxes | Powered by JetHome®