Re: [RFC PATCH 0/7] mm: defer address-space teardown of large exiting processes to a kthread

[Aditya Sharma]

Sent using Zoho Mail


From: David Hildenbrand (Arm) <david@xxxxxxxxxx>
To: "Aditya Sharma"<adi.sharma@xxxxxxxxxxx>, "Andrew Morton"<akpm@xxxxxxxxxxxxxxxxxxxx>, "Lorenzo Stoakes"<ljs@xxxxxxxxxx>, "Liam R . Howlett"<liam@xxxxxxxxxxxxx>, "Vlastimil Babka"<vbabka@xxxxxxxxxx>, "Mike Rapoport"<rppt@xxxxxxxxxx>, "Suren Baghdasaryan"<surenb@xxxxxxxxxx>, "Michal Hocko"<mhocko@xxxxxxxx>
Cc: "David Rientjes"<rientjes@xxxxxxxxxx>, "Shakeel Butt"<shakeel.butt@xxxxxxxxx>, "Jonathan Corbet"<corbet@xxxxxxx>, "Shuah Khan"<skhan@xxxxxxxxxxxxxxxxxxx>, "Steven Rostedt"<rostedt@xxxxxxxxxxx>, "Masami Hiramatsu"<mhiramat@xxxxxxxxxx>, "Mathieu Desnoyers"<mathieu.desnoyers@xxxxxxxxxxxx>, "Kees Cook"<kees@xxxxxxxxxx>, "Ingo Molnar"<mingo@xxxxxxxxxx>, "Peter Zijlstra"<peterz@xxxxxxxxxxxxx>, "Juri Lelli"<juri.lelli@xxxxxxxxxx>, "Vincent Guittot"<vincent.guittot@xxxxxxxxxx>, "Dietmar Eggemann"<dietmar.eggemann@xxxxxxx>, "Ben Segall"<bsegall@xxxxxxxxxx>, "Mel Gorman"<mgorman@xxxxxxx>, "Valentin Schneider"<vschneid@xxxxxxxxxx>, "K Prateek Nayak"<kprateek.nayak@xxxxxxx>, <linux-mm@xxxxxxxxx>, <linux-doc@xxxxxxxxxxxxxxx>, <linux-trace-kernel@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <imbrenda@xxxxxxxxxxxxx>
Date: Mon, 20 Jul 2026 13:43:34 +0530
Subject: Re: [RFC PATCH 0/7] mm: defer address-space teardown of large exiting processes to a kthread


 > QEMU has an rather short implementation for async teardown using
 > clone(CLONE_VM), which is IIRC essentially the result of Claudios previous
 > kernel work you note below.
 > 
 > So nothing got merged because the problem was solvable in userspace.

Thanks for this. My related works paragraph is wrong on this then. It
says that the s390 case was addressed with KVM specific async destruction,
but what you point to is QEMU's shadow process. I will correct that in v2.

Yeah, that CLONE_VM trick works, so I would measure and compare them
and get back.

I plan to measure:

- Memory return latency
- N concurrent shadow teardowns on N cpus vs the reaper.

One difference between CLONE_VM approach and CONFIG_ASYNC_MM_TEARDOWN
is that the shadow process has to be created by the process that would
be torn down itself. If that same behaviour is wanted on a workload
where we dont own the source, CONFIG_ASYNC_MM_TEARDOWN enables it here
as well. Also, in the QEMU case, it also means that the deferred teardown
decision was made without knowing how large the process might become.
CONFIG_ASYNC_MM_TEARDOWN adds a gate where for the exiting process,
RSS is evaluated againsts the current backlog before queuing it for
async teardown.

I will drop a follow up with numbers

Aditya