Re: [RFC] Per file OOM badness
From: Nicolai HÃhnle
Date: Tue Jan 30 2018 - 06:36:50 EST
On 30.01.2018 12:34, Michel DÃnzer wrote:
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.
Existing protocols pass DRM fds between processes though, don't they?
Not child processes perhaps, but special-casing that seems like awful
design.
Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.