On 2018-03-26 04:36 PM, Lucas Stach wrote:
Am Dienstag, den 30.01.2018, 11:28 +0100 schrieb Michal Hocko:
On Tue 30-01-18 10:29:10, Michel Dänzer wrote:
On 2018-01-24 12:50 PM, Michal Hocko wrote:
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?
How about the other way around: what APIs can we use to charge / "uncharge" memory to a process? If we have those, we can experiment with different places to call them.
add_mm_counter() and I would add a new counter e.g. MM_KERNEL_PAGES.
So is anyone still working on this? This is hurting us bad enough that I don't want to keep this topic rotting for another year.
If no one is currently working on this I would volunteer to give the simple "just account private, non-shared buffers in process RSS" a spin.
Sounds good. FWIW, I think shared buffers can also be easily handled by accounting them in each process which has a reference. But that's more of a detail, shouldn't make a big difference overall either way.