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

[Aditya Sharma]

Sent using Zoho Mail


From: Liam R . Howlett <liam@xxxxxxxxxxxxx>
To: "Aditya Sharma"<adi.sharma@xxxxxxxxxxx>
Cc: "Andrew Morton"<akpm@xxxxxxxxxxxxxxxxxxxx>, "David Hildenbrand"<david@xxxxxxxxxx>, "Lorenzo Stoakes"<ljs@xxxxxxxxxx>, "Vlastimil Babka"<vbabka@xxxxxxxxxx>, "Mike Rapoport"<rppt@xxxxxxxxxx>, "Suren Baghdasaryan"<surenb@xxxxxxxxxx>, "Michal Hocko"<mhocko@xxxxxxxx>, "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 03:58:47 +0530
Subject: Re: [RFC PATCH 0/7] mm: defer address-space teardown of large exiting processes to a kthread


 > 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 used claude opus 4.8 to refine commit messages (the design is mine, 
the model was used to convey the intentions concretely). Further, I used
claude fable 5 for drafting the cover letter and reviewing the series, where
it flagged issues (I fixed some of those by hand and some were fixed by fable itself,
which I then reviewed). It also assisted in writing the benchmark harness
behind the numbers and did the litmus test the cover letter mentions. Every numbers
was measured by me, on my hardware. I take full responsibily of the entire 
series.

My bad that I did not add an assisted-by tag. Should have added it to v1
v2 will add it to the patches

 > 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.

That's why the reaper's affinity is a preference, not a bind (patch 2).
It uses kthread_affine_preferred() with housekeeping mask, so it can be
re-affined. kthread_bind_mask() would have taken that away. On a hybrid cpu,
it can be affined(by the (super)user) to whichever cores are appropriate. 

I do not have numbers for P core and E core teardown costs. Will measure and
send them.

 > 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.

Yes, it does cost something. Five consecutive 4GB inline teardowns in my testing
costed 372ms in exit path, while 440 ms in the case of kthread drain for the same
(five teardowns on another cpu). This cost became 1.18x. For multi gb mms,
the memory to be reaped would be much larger than the cpu cache can hold.
For small mms (< 64 MB, configurable by sysctl), the teardowns happen inline. 

The oom_reaper already reaps the victim's address space from a remote context,
as returning memory matters more than locality of teardown.

 > 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.

This is not meant to speed up teardown. Rather the latency for someone waiting
on death is reduced. Killing a 16 GB redis cost 292.97ms before returning to
waitpid(). It costs 0.24 with async teardown. The memory itself was returned
in about 300ms.

"parallelized" - This series does not parallelize the teardown. The design is serial.
N procesess exiting together today would tear down concurrently today. The reaper here,
uses one thread (nice 19, affined to housekeeping mask).

The numbers in cover letter support that this work is memory bound rather than CPU bound.
In sync case: teardown is around 56 GB/s on my machine (1GB in 18.01 ms and 16GB in 282.16ms).
Thirty two concurrent 0.5GB exits reap in 157.42ms (around 101 GB/s). So, a concurrency
of 32 gets about 1.8x. The single reaper thread takes 650ms to clear the same (about 25 GB/s).
Thus, this serialization took 4x the drain time, but takes peak concurrency down to
one cpu. Memory actully comes back later. Whether that's a good tradeoff, depends on 
what else we wish to run on the box (open questions #1 in cover letter)

 > 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

It is off by default and opt in (sysctl), so anything that depends on the
current semantics, continues to work exactly the same by doing nothing.

Also, mmput_async() already defers the teardown to a workqueue. So, in the current
kernel, there already exists a way where continuing to the next thing
does not necessarily mean that the memory is reclaimed.

 > completed then you've just made it impossible to know when it has
 > happened.

There are three vmstat counters and two tracepoint (patch 6).
Someone who opts in to the mechanism, and does need to make sure that the
cleanup is completed, can use the counters and tracepoints.

 > Also, you've just made this extremely hard to debug if something is
 > missed.

There are reap tracepoints that carry the pid, so we can get per pid completion status.

However, there is no number indicating the current depth of the queue. The series addds queued,
sync and rejected counters. Will add a reaped counter in v2 so that current queue depth
can be estimated. Please mention what else tracability can be added to this,
and what senairo do you have in mind that these counters and tracepoints might not
cover. I can add those to v2 as well.

 > 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.

This does not compete with with current teardown path. it goes through the
same exit_mm(). Any future improvements there, also improve the reaper's drain
times.

Thanks

Aditya