Re: [PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem

From: Michal Hocko <mhocko@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: "Greathouse, Joseph" <joseph.greathouse@amd.com>,
	"Kenny Ho" <Kenny.Ho@amd.com>,
	"Kuehling, Felix" <felix.kuehling@amd.com>,
	jsparks@cray.com, "amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	lkaplan@cray.com, "Kenny Ho" <y2kenny@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	cgroups@vger.kernel.org,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem
Date: Tue, 10 Sep 2019 19:25:53 +0200	[thread overview]
Message-ID: <20190910172553.GA4023@dhcp22.suse.cz> (raw)
In-Reply-To: <20190910160329.GR2263813@devbig004.ftw2.facebook.com>

On Tue 10-09-19 09:03:29, Tejun Heo wrote:
> Hello, Michal.
> 
> On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> > > So, while it'd great to have shrinkers in the longer term, it's not a
> > > strict requirement to be accounted in memcg.  It already accounts a
> > > lot of memory which isn't reclaimable (a lot of slabs and socket
> > > buffer).
> > 
> > Yeah, having a shrinker is preferred but the memory should better be
> > reclaimable in some form. If not by any other means then at least bound
> > to a user process context so that it goes away with a task being killed
> > by the OOM killer. If that is not the case then we cannot really charge
> > it because then the memcg controller is of no use. We can tolerate it to
> > some degree if the amount of memory charged like that is negligible to
> > the overall size. But from the discussion it seems that these buffers
> > are really large.
> 
> Yeah, oom kills should be able to reduce the usage; however, please
> note that tmpfs, among other things, can already escape this
> restriction and we can have cgroups which are over max and empty.
> It's obviously not ideal but the system doesn't melt down from it
> either.

Right, and that is a reason why an access to tmpfs should be restricted
when containing a workload by memcg. My understanding of this particular
feature is that memcg should be the primary containment method and
that's why I brought this up.

-- 
Michal Hocko
SUSE Labs
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel