From: Johannes Weiner <hannes@cmpxchg.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, "Alex Deucher" <alexander.deucher@amd.com>,
"Greathouse, Joseph" <joseph.greathouse@amd.com>,
"amd-gfx mailing list" <amd-gfx@lists.freedesktop.org>,
"Jason Ekstrand" <jason@jlekstrand.net>,
"Tejun Heo" <tj@kernel.org>,
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: Wed, 19 Feb 2020 13:38:41 -0500 [thread overview]
Message-ID: <20200219183841.GA54486@cmpxchg.org> (raw)
In-Reply-To: <CAOWid-e=7V4TUqK_h5Gs9dUXqH-Vgr-Go8c1dCkMux98Vdd1sQ@mail.gmail.com>
On Wed, Feb 19, 2020 at 11:28:48AM -0500, Kenny Ho wrote:
> On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
> >
> > Yes, I'd go with absolute units when it comes to memory, because it's
> > not a renewable resource like CPU and IO, and so we do have cliff
> > behavior around the edge where you transition from ok to not-enough.
> >
> > memory.low is a bit in flux right now, so if anything is unclear
> > around its semantics, please feel free to reach out.
>
> I am not familiar with the discussion, would you point me to a
> relevant thread please?
Here is a cleanup patch, not yet merged, that documents the exact
semantics and behavioral considerations:
https://lore.kernel.org/linux-mm/20191213192158.188939-3-hannes@cmpxchg.org/
But the high-level idea is this: you assign each cgroup or cgroup
subtree a chunk of the resource that it's guaranteed to be able to
consume. It *can* consume beyond that threshold if available, but that
overage may get reclaimed again if somebody else needs it instead.
This allows you to do a ballpark distribution of the resource between
different workloads, while the kernel retains the ability to optimize
allocation of spare resources - because in practice, workload demand
varies over time, workloads disappear and new ones start up etc.
> In addition, is there some kind of order of preference for
> implementing low vs high vs max?
If you implement only one allocation model, the preference would be on
memory.low. Limits are rigid and per definition waste resources, so in
practice we're moving away from them.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-02-20 8:45 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
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 [this message]
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=20200219183841.GA54486@cmpxchg.org \
--to=hannes@cmpxchg.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=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=tj@kernel.org \
--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).