On Wed, Nov 08, 2023 at 01:03:33AM +0100, Mateusz Guzik wrote: > [...] > >>@[ > >> __pv_queued_spin_lock_slowpath+1 > >> _raw_spin_lock_irq+43 > >> wait_for_completion+141 > >> stop_one_cpu+127 > >> sched_exec+165 > > > > There's the suspicious sched_exec() I was talking about! :) > > > > I think it needs to be moved, and perhaps _later_ instead of earlier? > > Hmm... > > > > I'm getting around 3.4k execs/s. However, if I "taskset -c 3 > ./static-doexec 1" the number goes up to about 9.5k and lock > contention disappears from the profile. So off hand looks like the > task is walking around the box when it perhaps could be avoided -- it > is idle apart from running the test. Again this is going to require a > serious look instead of ad hoc pokes. Hm, that is pretty interesting. I'll see if I can go find the original rationale for adding sched_exec() in there... > Side note I actually read your patch this time around instead of > skimming through it and assuming it did what I thought. > > do_filp_open is of course very expensive and kmalloc + kfree are slow. > On top of it deallocating a file object even after a failed open was > very expensive due to delegation to task_work (recently fixed). > > What I claim should be clear-cut faster is that lookup as in the > original patch and only messing with file allocation et al if it > succeeds. I'm less familiar with the VFS guts here -- I'm open to alternatives! :) -- Kees Cook
