Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 13.06.22 um 14:11 schrieb Michal Hocko:
[SNIP]
Alternative I could try to track the "owner" of a buffer (e.g. a shmem
file), but then it can happen that one processes creates the object and
another one is writing to it and actually allocating the memory.
If you can enforce that the owner is really responsible for the
allocation then all should be fine. That would require MAP_POPULATE like
semantic and I suspect this is not really feasible with the existing
userspace. It would be certainly hard to enforce for bad players.
I've tried this today and the result was: "BUG: Bad rss-counter state
mm:000000008751d9ff type:MM_FILEPAGES val:-571286".

The problem is once more that files are not informed when the process
clones. So what happened is that somebody called fork() with an mm_struct
I've accounted my pages to. The result is just that we messed up the
rss_stats and  the the "BUG..." above.

The key difference between normal allocated pages and the resources here is
just that we are not bound to an mm_struct in any way.
It is not really clear to me what exactly you have tried.

I've tried to track the "owner" of a driver connection by keeping a reference to the mm_struct who created this connection inside our file private and then use add_mm_counter() to account all the allocations of the driver to this mm_struct.

This works to the extend that now the right process is killed in an OOM situation. The problem with this approach is that the driver is not informed about operations like fork() or clone(), so what happens is that after a fork()/clone() we have an unbalanced rss-counter.

Let me maybe get back to the initial question: We have resources which are not related to the virtual address space of a process, how should we tell the OOM killer about them?

Thanks for all the input so far,
Christian.



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux