dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Kenny Ho <y2kenny@gmail.com>
Cc: juan.zuniga-anaya@amd.com, "Kenny Ho" <Kenny.Ho@amd.com>,
	"Kuehling, Felix" <felix.kuehling@amd.com>,
	jsparks@cray.com, nirmoy.das@amd.com,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	lkaplan@cray.com, "Greathouse,
	Joseph" <joseph.greathouse@amd.com>,
	"amd-gfx mailing list" <amd-gfx@lists.freedesktop.org>,
	"Jason Ekstrand" <jason@jlekstrand.net>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	cgroups@vger.kernel.org,
	"Christian König" <christian.koenig@amd.com>,
	damon.mcdougall@amd.com
Subject: Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Date: Fri, 14 Feb 2020 14:17:54 -0500	[thread overview]
Message-ID: <20200214191754.GA218629@mtj.thefacebook.com> (raw)
In-Reply-To: <CAOWid-caJHeXUnQv3MOi=9U+vdBLfewN+CrA-7jRrz0VXqatbQ@mail.gmail.com>

Hello, Kenny, Daniel.

(cc'ing Johannes)

On Fri, Feb 14, 2020 at 01:51:32PM -0500, Kenny Ho wrote:
> On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > I think guidance from Tejun in previos discussions was pretty clear that
> > he expects cgroups to be both a) standardized and c) sufficient clear
> > meaning that end-users have a clear understanding of what happens when
> > they change the resource allocation.
> >
> > I'm not sure lgpu here, at least as specified, passes either.
> 
> I disagree (at least on the characterization of the feedback
> provided.)  I believe this series satisfied the sprite of Tejun's
> guidance so far (the weight knob for lgpu, for example, was
> specifically implemented base on his input.)  But, I will let Tejun
> speak for himself after he considered the implementation in detail.

I have to agree with Daniel here. My apologies if I weren't clear
enough. Here's one interface I can think of:

 * compute weight: The same format as io.weight. Proportional control
   of gpu compute.

 * memory low: Please see how the system memory.low behaves. For gpus,
   it'll need per-device entries.

Note that for both, there one number to configure and conceptually
it's pretty clear to everybody what that number means, which is not to
say that it's clear to implement but it's much better to deal with
that on this side of the interface than the other.

cc'ing Johannes. Do you have anything on mind regarding how gpu memory
configuration should look like? e.g. should it go w/ weights rather
than absoulte units (I don't think so given that it'll most likely
need limits at some point too but still and there are benefits from
staying consistent with system memory).

Also, a rather trivial high level question. Is drm a good controller
name given that other controller names are like cpu, memory, io?

Thanks.

-- 
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-02-14 19:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14 15:56 [PATCH 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
2020-02-14 15:56 ` [PATCH 01/11] cgroup: Introduce cgroup for drm subsystem Kenny Ho
2020-02-14 15:56 ` [PATCH 02/11] drm, cgroup: Bind drm and cgroup subsystem Kenny Ho
2020-02-14 15:56 ` [PATCH 03/11] drm, cgroup: Initialize drmcg properties Kenny Ho
2020-02-14 15:56 ` [PATCH 04/11] drm, cgroup: Add total GEM buffer allocation stats Kenny Ho
2020-02-14 15:56 ` [PATCH 05/11] drm, cgroup: Add peak " Kenny Ho
2020-02-14 15:56 ` [PATCH 06/11] drm, cgroup: Add GEM buffer allocation count stats Kenny Ho
2020-02-14 15:56 ` [PATCH 07/11] drm, cgroup: Add total GEM buffer allocation limit Kenny Ho
2020-02-14 15:56 ` [PATCH 08/11] drm, cgroup: Add peak " Kenny Ho
2020-02-14 15:56 ` [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource Kenny Ho
2020-02-14 16:44   ` Jason Ekstrand
2020-02-14 16:59     ` Jason Ekstrand
2020-02-14 17:08     ` Kenny Ho
2020-02-14 17:48       ` Jason Ekstrand
2020-02-14 18:34       ` Daniel Vetter
2020-02-14 18:51         ` Kenny Ho
2020-02-14 19:17           ` Tejun Heo [this message]
2020-02-14 20:28             ` Kenny Ho
2020-02-14 21:15               ` Tejun Heo
2020-02-19 16:21               ` Johannes Weiner
2020-02-19 16:18             ` Johannes Weiner
2020-02-19 16:28               ` Kenny Ho
2020-02-19 18:38                 ` Johannes Weiner
2020-02-21  5:59                   ` Kenny Ho
2020-02-14 15:56 ` [PATCH 10/11] drm, cgroup: add update trigger after limit change Kenny Ho
2020-02-14 15:56 ` [PATCH 11/11] drm/amdgpu: Integrate with DRM cgroup Kenny Ho

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=20200214191754.GA218629@mtj.thefacebook.com \
    --to=tj@kernel.org \
    --cc=Kenny.Ho@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=cgroups@vger.kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=damon.mcdougall@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --cc=hannes@cmpxchg.org \
    --cc=jason@jlekstrand.net \
    --cc=joseph.greathouse@amd.com \
    --cc=jsparks@cray.com \
    --cc=juan.zuniga-anaya@amd.com \
    --cc=lkaplan@cray.com \
    --cc=nirmoy.das@amd.com \
    --cc=y2kenny@gmail.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;
as well as URLs for NNTP newsgroup(s).