Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource

From: Kenny Ho <y2kenny@gmail.com>
To: Johannes Weiner <hannes@cmpxchg.org>
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: Fri, 21 Feb 2020 00:59:55 -0500	[thread overview]
Message-ID: <CAOWid-dLs079jHAVoDeJ2Ung1Tti0Jszhd-0D2RYPOjuWnTprQ@mail.gmail.com> (raw)
In-Reply-To: <20200219183841.GA54486@cmpxchg.org>

Thanks, I will take a look.

Regards,
Kenny

On Wed, Feb 19, 2020 at 1:38 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> 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