Message ID | 20211111095008.264412-1-imbrenda@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | Two alternatives for mm async teardown | expand |
On Thu 11-11-21 10:50:03, Claudio Imbrenda wrote: > This RFC series proposes two possible ways for enabling asynchronous mm > teardown. It would be great to describe an intended usecase here and also explain why the existing features do not allow the required functionality. Please also make sure to cc linux-api when adding a new user visible interface or changing a visible behavior of existing one. E.g. why cannot you simply create a process outside of the thread group yet share the mm with your task. Once the other process exits which you can detect then you just exit that process and do the finall clean up from that context? > The first approach, in patch 1, is simply to provide an arch hook in > exit_mm. This has no functional change for archs that don't explicitly > use the hook, and leaves the hard part to arch code (including > accounting, if any). This is just too vague but I have to say I am not really a fan of hooks that considerably change the existing behavior. > The second approach, in patches 2 to 4, adds a new syscall to allow an > mm to be asynchronously torn down in the context of another process > (similarly to how process_mrelease works). It also adds an OOM notifier > to prevent the OOM killer from killing processes while the teardown is > in progress. I have to say I do not like oom notifier part at all. You can have different sources of the OOM (memcg, cpusets or global oom). It is impossible to tell those appart in the notifier. Not to mention that memcg oom is explicitly avoiding notifiers altogether.