On 26/07/20 12:24AM, Aditya Sharma wrote: > Address-space teardown on process exit runs synchronously in the dying > task's context: exit_mm() -> mmput() -> __mmput() -> exit_mmap() walks > page tables, updates rmap, frees the RSS and drops file references, all > on the exiting CPU. For a multi-GB process that is hundreds of > milliseconds of exit-path latency, paid by whoever is waiting on the > death: a supervisor's kill-and-respawn cycle, a shell's waitpid(), an > orchestrator reaping a fleet of workers. On the test box below, killing > a 16GB process costs ~280ms before the parent's waitpid() returns. > > This series adds CONFIG_ASYNC_MM_TEARDOWN: an opt-in, default-off path > that defers __mmput() of large exiting processes to a dedicated kernel > thread (mm_reaper), so the exiting CPU is released as soon as the task > is reaped and the teardown runs off to the side.
This reads like it was written by an AI, but there is no assisted-by tags. Which AI did you use to generate these patches and/or cover letter? I do not see a benefit to running the task cleanup 'off the side'. In modern computers, that may mean switching core types that run at different speeds. Regardless of speed, the CPU that will be doing the work is remote to the workload by design, (or may be, depending on the scheduling?). That is, you are tasking another CPU to do cleanup of local CPU-aware information.. The ideal CPU to do a task exit is the one that's doing it already. There are hidden costs to your approach and I don't really understand how this could possibly speed things up - even parallelized tasks will take more CPU time in total, even if locking issues are avoided. Sure, the task waiting for cleanup to complete may think it's done and continue to do the Next Thing - but if it really needs the cleanup to be completed then you've just made it impossible to know when it has happened. Also, you've just made this extremely hard to debug if something is missed. The work that is done in teardown is necessary. Your time (and tokens?) would be better spent trying to improve what we have to do instead of shifting the work around. Thanks, Liam
