Hi Andy, ---- On Fri, 29 May 2026 02:27:00 +0800 Andy Lutomirski <[email protected]> wrote --- > On Thu, May 28, 2026 at 2:55 AM Li Chen <[email protected]> wrote: > > > > > > > The template pins the executable and denies writes to that file while the > > template fd is alive, > > Please don't. *Maybe* detect when it gets modified and clear your cache. > > Or develop a generic way to open a new fd that's an immutable view > into an existing file such that the fd retains its contents even if > the file changes. (Think a reflink that's not persistent and has no > name -- you'll need some way to avoid resource exhaustion.)
I agree that deny-write is not a good long-term invalidation model. I had considered clear-cache-on-modify, but kept this RFC smaller. > > > > Workload Calls subprocess spawn_template time_s Delta > > (workers) calls calls/s calls/s seconds > > 1x16 6144 411.04 420.32 14.95/14.62 +2.26% > > 2x8 6144 666.78 690.08 9.21/8.90 +3.49% > > 4x4 6144 955.61 1003.25 6.43/6.12 +4.99% > > 8x2 6144 1048.25 1069.18 5.86/5.75 +2.00% > > This is a lot of complexity in the kernel for a teeny tiny gain. > > I'm with Christian -- a better spawn API would be great (and much > faster than fork/vfork + exec), but that's a different patch. Thanks, I agree. A pidfd/pidfs spawn builder looks like the much better API shape. The cover letter numbers were from a mixed agent-tool workload. For very short single-tool runs I saw larger wins, about +14% for printf-style work. I should have called that out separately. I will work toward a pidfd_config-style builder next. Regards, Li
