Re: [RFC] Per file OOM badness

From: Christian KÃnig
Date: Wed Jan 24 2018 - 07:11:18 EST


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.

Regards,
Christian.