[RFC PATCH v2 4/5] drm, cgroup: Add total GEM buffer allocation limit

[Koenig, Christian]

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.
> https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#issues-with-v1-and-rationales-for-v2

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 
times.

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?

Regards,
Christian.

>
> Regards,
> Kenny
>
>>> 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.
>>
>> Thanks,
>> Christian.
>>
>>> I should probably summarize some of these into the commit message.
>>>
>>> Regards,
>>> Kenny
>>>
>>>
>>>
>>>> Christian.
>>>>