On Thu, Jun 27, 2019 at 1:43 AM Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Wed, Jun 26, 2019 at 06:41:32PM -0400, Kenny Ho wrote: > > So without the sharing restriction and some kind of ownership > > structure, we will have to migrate/change the owner of the buffer when > > the cgroup that created the buffer die before the receiving cgroup(s) > > and I am not sure how to do that properly at the moment. 1) Should > > each cgroup keep track of all the buffers that belongs to it and > > migrate? (Is that efficient?) 2) which cgroup should be the new > > owner (and therefore have the limit applied?) Having the creator > > being the owner is kind of natural, but let say the buffer is shared > > with 5 other cgroups, which of these 5 cgroups should be the new owner > > of the buffer? > > Different answers: > > - Do we care if we leak bos like this in a cgroup, if the cgroup > disappears before all the bo are cleaned up? > > - Just charge the bo to each cgroup it's in? Will be quite a bit more > tracking needed to get that done ... That seems to be the approach memcg takes, but as shown by the lwn link you sent me from the last rfc (talk from Roman Gushchin), that approach is not problem free either. And wouldn't this approach disconnect resource management from the underlying resource one would like to control? For example, if you have 5 MB of memory, you can have 5 users using 1 MB each. But in the charge-everybody approach, a 1 MB usage shared 4 times will make it looks like 5MB is used. So the resource being control is no longer 'real' since the amount of resource you have is now dynamic and depends on the amount of sharing one does. > - Also, there's the legacy way of sharing a bo, with the FLINK and > GEM_OPEN ioctls. We need to plug these holes too. > > Just feels like your current solution is technically well-justified, but > it completely defeats the point of cgroups/containers and buffer sharing > ... Um... I am going to get a bit philosophical here and suggest that the idea of sharing (especially uncontrolled sharing) is inherently at odd with containment. It's like, if everybody is special, no one is special. Perhaps an alternative is to make this configurable so that people can allow sharing knowing the caveat? And just to be clear, the current solution allows for sharing, even between cgroup. Regards, Kenny _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
