On Tue, Sep 16, 2025 at 11:34:24AM +0200 Claudio Jeker wrote:
> On Sun, Sep 14, 2025 at 10:36:51PM +0200, Christian Ludwig wrote:
> > Hi,
> > 
> > this is another attempt to get rid of the dedicated reaper thread.
> 
> Why is this a goal? What problem are you trying to solve with this?

It's about resource accounting. The reaper accounts for CPU time that
should be spent in the exiting process. Another thing that itches me is
that we force-switch to idle. We account idle time for stuff that deals
with process exit.
 
> In my opinion this diff makes the current exit situation worse. Instead of
> having a clear reaper process that does the cleanup of the proc and
> process we now end up delegating this work to init(8) or the parent
> process. Neither are really ideal to do this work.

As Martin said, the parent frees the child's resources already. The
reaper only handles PS_NOZOMBIE processes and threads. The processes
have been reparented to init anyway, now it accounts for the time.

> You can not assume the parent will be sitting in wait(2) / dowait6() on
> exit of a child.  Actually you can not assume that the parent will ever
> call wait(2) so this change would allow the collection of many fat zombies
> for no goood reason.

Not calling wait(2) and accumulating zombies? Does not sound like a good
citizen to me. That's what rlimit is for, I guess.

> Wait(2) only needs a few bit of information (r- and tusage, signal and exit
> information) to work, so things like the uarea really should be removed
> early on and not linger around until the zombie is collected.

Considering that the time for freeing the uarea should be accounted
properly, I see no way to free *that* earlier. But I'm open for ideas.
I agree that more code should move to exit1() to keep the janitor work
in the parent/init as short as we can and the memory footprint low.

> The reaper right now is no longer a bottle neck, it uses very CPU little
> time.  I agree that moving more from the reaper into exit1() is a good
> thing, like the wakeup signaling to the parent process. But I think this
> goes a few steps to far and introduces complex problems for very little
> benefit.
> 
> For me the reaper thread by itself is not an issue, it helps to finish up
> the tricky bits of cleanup on exit quickly.

The reaper frees some resources even for zombies. It does that
sequentially. Moving that code allows for parallel execution.

And if you take out these bits, and the parent signalling code, there is
not much left of the reaper.


 - Christian