On 2018-01-30 10:31 AM, Daniel Vetter wrote: > On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote: >> Am 24.01.2018 um 12:50 schrieb Michal Hocko: >>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote: >>>> On 2018-01-24 12:01 PM, Michal Hocko wrote: >>>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote: >>> [...] >>>>>> 2. If the OOM killer kills a process which is sharing BOs with another >>>>>> process, this should result in the other process dropping its references >>>>>> to the BOs as well, at which point the memory is released. >>>>> OK. How exactly are those BOs mapped to the userspace? >>>> I'm not sure what you're asking. Userspace mostly uses a GEM handle to >>>> refer to a BO. There can also be userspace CPU mappings of the BO's >>>> memory, but userspace doesn't need CPU mappings for all BOs and only >>>> creates them as needed. >>> OK, I guess you have to bear with me some more. This whole stack is a >>> complete uknonwn. I am mostly after finding a boundary where you can >>> charge the allocated memory to the process so that the oom killer can >>> consider it. Is there anything like that? Except for the proposed file >>> handle hack? >> >> Not that I knew of. >> >> As I said before we need some kind of callback that a process now starts to >> use a file descriptor, but without anything from that file descriptor mapped >> into the address space. > > For more context: With DRI3 and wayland the compositor opens the DRM fd > and then passes it to the client, which then starts allocating stuff. That > makes book-keeping rather annoying. Actually, what you're describing is only true for the buffers shared by an X server with an X11 compositor. For the actual applications, the buffers are created on the client side and then shared with the X server / Wayland compositor. Anyway, it doesn't really matter. In all cases, the buffers are actually used by all parties that are sharing them, so charging the memory to all of them is perfectly appropriate. > I guess a good first order approximation would be if we simply charge any > newly allocated buffers to the process that created them, but that means > hanging onto lots of mm_struct pointers since we want to make sure we then > release those pages to the right mm again (since the process that drops > the last ref might be a totally different one, depending upon how the > buffers or DRM fd have been shared). > > Would it be ok to hang onto potentially arbitrary mmget references > essentially forever? If that's ok I think we can do your process based > account (minus a few minor inaccuracies for shared stuff perhaps, but no > one cares about that). Honestly, I think you and Christian are overthinking this. Let's try charging the memory to every process which shares a buffer, and go from there. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
