Sent using Zoho Mail
From: Liam R . Howlett <[email protected]>
To: "Aditya Sharma"<[email protected]>
Cc: "Andrew Morton"<[email protected]>, "David
Hildenbrand"<[email protected]>, "Lorenzo Stoakes"<[email protected]>, "Vlastimil
Babka"<[email protected]>, "Mike Rapoport"<[email protected]>, "Suren
Baghdasaryan"<[email protected]>, "Michal Hocko"<[email protected]>, "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 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
