[RFC PATCH v2 4/5] drm, cgroup: Add total GEM buffer allocation limit
Christian.Koenig at amd.com
Fri May 10 17:48:32 UTC 2019
Am 10.05.19 um 17:25 schrieb Kenny Ho:
> [CAUTION: External Email]
> On Fri, May 10, 2019 at 11:08 AM Koenig, Christian
> <Christian.Koenig at amd.com> wrote:
>> Am 10.05.19 um 16:57 schrieb Kenny Ho:
>>> On Fri, May 10, 2019 at 8:28 AM Christian König
>>> <ckoenig.leichtzumerken at gmail.com> wrote:
>>>> Am 09.05.19 um 23:04 schrieb Kenny Ho:
>> So the drm cgroup container is separate to other cgroup containers?
> In cgroup-v1, which is most widely deployed currently, all controllers
> have their own hierarchy (see /sys/fs/cgroup/). In cgroup-v2, the
> hierarchy is unified by individual controllers can be disabled (I
> believe, I am not super familiar with v2.)
>> In other words as long as userspace doesn't change, this wouldn't have
>> any effect?
> As far as things like docker and podman is concern, yes. I am not
> sure about the behaviour of others like lxc, lxd, etc. because I
> haven't used those myself.
>> Well that is unexpected cause then a processes would be in different
>> groups for different controllers, but if that's really the case that
>> would certainly work.
> I believe this is a possibility for v1 and is why folks came up with
> the unified hierarchy in v2 to solve some of the issues.
Well another question is why do we want to prevent that in the first place?
I mean the worst thing that can happen is that we account a BO multiple
And going into the same direction where is the code to handle an open
device file descriptor which is send from one cgroup to another?
>>> On the other hand, if there are expectations for resource management
>>> between containers, I would like to know who is the expected manager
>>> and how does it fit into the concept of container (which enforce some
>>> level of isolation.) One possible manager may be the display server.
>>> But as long as the display server is in a parent cgroup of the apps'
>>> cgroup, the apps can still import handles from the display server
>>> under the current implementation. My understanding is that this is
>>> most likely the case, with the display server simply sitting at the
>>> default/root cgroup. But I certainly want to hear more about other
>>> use cases (for example, is running multiple display servers on a
>>> single host a realistic possibility? Are there people running
>>> multiple display servers inside peer containers? If so, how do they
>>> coordinate resources?)
>> We definitely have situations with multiple display servers running
>> (just think of VR).
>> I just can't say if they currently use cgroups in any way.
>>> I should probably summarize some of these into the commit message.
More information about the amd-gfx