Messages in this thread | | | Subject | Re: [RFC] Per file OOM badness | From | Michel Dänzer <> | Date | Tue, 30 Jan 2018 12:34:18 +0100 |
| |
On 2018-01-30 12:28 PM, Christian König wrote: > Am 30.01.2018 um 12:02 schrieb Michel Dänzer: >> On 2018-01-30 11:40 AM, Christian König wrote: >>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer: >>>> [SNIP] >>>>> 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. >>> My problem is that this needs to be bullet prove. >>> >>> For example imagine an application which allocates a lot of BOs, then >>> calls fork() and let the parent process die. The file descriptor lives >>> on in the child process, but the memory is not accounted against the >>> child. >> What exactly are you referring to by "the file descriptor" here? > > The file descriptor used to identify the connection to the driver. In > other words our drm_file structure in the kernel. > >> What happens to BO handles in general in this case? If both parent and >> child process keep the same handle for the same BO, one of them >> destroying the handle will result in the other one not being able to use >> it anymore either, won't it? > Correct. > > That usage is actually not useful at all, but we already had > applications which did exactly that by accident. > > Not to mention that somebody could do it on purpose.
Can we just prevent child processes from using their parent's DRM file descriptors altogether? Allowing it seems like a bad idea all around.
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
| |