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@xxxxxxx> 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@xxxxxxxxx> 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. >>>> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
