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

Sent using Zoho Mail


From: David Hildenbrand (Arm) <[email protected]>
To: "Aditya Sharma"<[email protected]>, "Andrew Morton"<[email protected]>, "Lorenzo Stoakes"<[email protected]>, "Liam R . Howlett"<[email protected]>, "Vlastimil Babka"<[email protected]>, "Mike Rapoport"<[email protected]>, "Suren Baghdasaryan"<[email protected]>, "Michal Hocko"<[email protected]>
Cc: "David Rientjes"<[email protected]>, "Shakeel Butt"<[email protected]>, "Jonathan Corbet"<[email protected]>, "Shuah Khan"<[email protected]>, "Steven Rostedt"<[email protected]>, "Masami Hiramatsu"<[email protected]>, "Mathieu Desnoyers"<[email protected]>, "Kees Cook"<[email protected]>, "Ingo Molnar"<[email protected]>, "Peter Zijlstra"<[email protected]>, "Juri Lelli"<[email protected]>, "Vincent Guittot"<[email protected]>, "Dietmar Eggemann"<[email protected]>, "Ben Segall"<[email protected]>, "Mel Gorman"<[email protected]>, "Valentin Schneider"<[email protected]>, "K Prateek Nayak"<[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>
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