Index | Thread | Search

From:
Mark Kettenis <mark.kettenis@xs4all.nl>
Subject:
Re: Faster _exit(2) for a faster userland: R.I.P the reaper
To:
Claudio Jeker <claudio@openbsd.org>
Cc:
tedu@tedunangst.com, dlg@openbsd.org, visa@openbsd.org, tech@openbsd.org, jan@openbsd.org, mpi@grenadille.net, ajacoutot@openbsd.org
Date:
Mon, 05 May 2025 21:25:27 +0200

Download raw body.

Thread
  • Marc Espie:

    Faster _exit(2) for a faster userland: R.I.P the reaper

  • > Date: Sat, 3 May 2025 14:06:45 +0200
    > From: Claudio Jeker <claudio@openbsd.org>
    > 
    > On Sat, May 03, 2025 at 02:08:35AM -0400, Ted Unangst wrote:
    > > On 2025-05-03, Claudio Jeker wrote:
    > > 
    > > > I mentioned this to mpi@, his diff does not free threads until
    > > > the process exits and runs out of proc on any workload that uses
    > > > many threads.  This just does not work, his diff is over
    > > > agressive by removing the reaper even for that one case..
    > > 
    > > I think that chunk can be pulled up a little in exit1, so that when one
    > > thread exits, it will delete any dead siblings. Need a P_ZOMBIE, or a
    > > pr_deadproc list. This seems like an old idea? Did I forgot why we
    > > rejected it?
    > 
    > I do not understand why we can't keep the reaper just for this. The work
    > needed for releasing struct proc and its uarea is minimal. Why delay it
    > until the next thread exits?
    > 
    > There is no need to remove the reaper but we need to move the heavy uvm
    > teardown out of it.
    
    Right.  I think the process should be to move stuff step by step.  If
    at some point we have little left in the reaper we can think consider
    if there is a better way to handle those bits.
    
    
  • Marc Espie:

    Faster _exit(2) for a faster userland: R.I.P the reaper