linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Welty, Brian" <brian.welty@intel.com>
To: Tejun Heo <tj@kernel.org>
Cc: cgroups@vger.kernel.org, "Li Zefan" <lizefan@huawei.com>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	linux-mm@kvack.org, "Michal Hocko" <mhocko@kernel.org>,
	"Vladimir Davydov" <vdavydov.dev@gmail.com>,
	dri-devel@lists.freedesktop.org,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	"Christian König" <christian.koenig@amd.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"RDMA mailing list" <linux-rdma@vger.kernel.org>,
	"Leon Romanovsky" <leon@kernel.org>,
	kenny.ho@amd.com
Subject: Re: [RFC PATCH 0/5] cgroup support for GPU devices
Date: Tue, 7 May 2019 12:50:50 -0700	[thread overview]
Message-ID: <cf58b047-d678-ad89-c9b6-96fc6b01c1d7@intel.com> (raw)
In-Reply-To: <20190506152643.GL374014@devbig004.ftw2.facebook.com>


On 5/6/2019 8:26 AM, Tejun Heo wrote:
> Hello,
> 
> On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
>> The patch series enables device drivers to use cgroups to control the
>> following resources within a GPU (or other accelerator device):
>> *  control allocation of device memory (reuse of memcg)
>> and with future work, we could extend to:
>> *  track and control share of GPU time (reuse of cpu/cpuacct)
>> *  apply mask of allowed execution engines (reuse of cpusets)
>>
>> Instead of introducing a new cgroup subsystem for GPU devices, a new
>> framework is proposed to allow devices to register with existing cgroup
>> controllers, which creates per-device cgroup_subsys_state within the
>> cgroup.  This gives device drivers their own private cgroup controls
>> (such as memory limits or other parameters) to be applied to device
>> resources instead of host system resources.
>> Device drivers (GPU or other) are then able to reuse the existing cgroup
>> controls, instead of inventing similar ones.
> 
> I'm really skeptical about this approach.  When creating resource
> controllers, I think what's the most important and challenging is
> establishing resource model - what resources are and how they can be
> distributed.  This patchset is going the other way around - building
> out core infrastructure for bolierplates at a significant risk of
> mixing up resource models across different types of resources.
> 
> IO controllers already implement per-device controls.  I'd suggest
> following the same interface conventions and implementing a dedicated
> controller for the subsystem.
>
Okay, thanks for feedback.  Preference is clear to see this done as
dedicated cgroup controller.

Part of my proposal was an attempt for devices with "mem like" and "cpu 
like" attributes to be managed by common controller.   We can ignore this
idea for cpu attributes, as those can just go in a GPU controller.

There might still be merit in having a 'device mem' cgroup controller.
The resource model at least is then no longer mixed up with host memory.
RDMA community seemed to have some interest in a common controller at
least for device memory aspects.
Thoughts on this?   I believe could still reuse the 'struct mem_cgroup' data
structure.  There should be some opportunity to reuse charging APIs and
have some nice integration with HMM for charging to device memory, depending
on backing store.

-Brian


  reply	other threads:[~2019-05-07 19:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-01 14:04 [RFC PATCH 0/5] cgroup support for GPU devices Brian Welty
2019-05-01 14:04 ` [RFC PATCH 1/5] cgroup: Add cgroup_subsys per-device registration framework Brian Welty
2019-05-01 14:04 ` [RFC PATCH 2/5] cgroup: Change kernfs_node for directories to store cgroup_subsys_state Brian Welty
2019-05-01 14:04 ` [RFC PATCH 3/5] memcg: Add per-device support to memory cgroup subsystem Brian Welty
2019-05-01 14:04 ` [RFC PATCH 4/5] drm: Add memory cgroup registration and DRIVER_CGROUPS feature bit Brian Welty
2019-05-01 14:04 ` [RFC PATCH 5/5] drm/i915: Use memory cgroup for enforcing device memory limit Brian Welty
2019-05-02  8:34 ` [RFC PATCH 0/5] cgroup support for GPU devices Leon Romanovsky
2019-05-02 22:48   ` Kenny Ho
2019-05-03 21:14     ` Welty, Brian
2019-05-05  7:14       ` Leon Romanovsky
2019-05-05 14:21         ` Kenny Ho
2019-05-05 16:05           ` Leon Romanovsky
2019-05-05 16:34             ` Kenny Ho
2019-05-05 16:55               ` Leon Romanovsky
2019-05-05 16:46             ` Chris Down
2019-05-06 15:16 ` Johannes Weiner
2019-05-06 15:26 ` Tejun Heo
2019-05-07 19:50   ` Welty, Brian [this message]
2019-05-09 16:52     ` Tejun Heo

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=cf58b047-d678-ad89-c9b6-96fc6b01c1d7@intel.com \
    --to=brian.welty@intel.com \
    --cc=airlied@linux.ie \
    --cc=cgroups@vger.kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hannes@cmpxchg.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jglisse@redhat.com \
    --cc=kenny.ho@amd.com \
    --cc=leon@kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mhocko@kernel.org \
    --cc=tj@kernel.org \
    --cc=vdavydov.dev@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).