On 01/06/19(Sat) 15:54, Mark Kettenis wrote:
> > Date: Sat, 25 May 2019 15:57:44 -0300
> > From: Martin Pieuchot <m...@openbsd.org>
> >
> > On 12/05/19(Sun) 18:17, Martin Pieuchot wrote:
> > > People started complaining that the SCHED_LOCK() is contended. Here's a
> > > first round at reducing its scope.
> > >
> > > Diff below introduces a per-process mutex to protect time accounting
> > > fields accessed in tuagg(). tuagg() is principally called in mi_switch()
> > > where the SCHED_LOCK() is currently held. Moving these fields out of
> > > its scope allows us to drop some SCHED_LOCK/UNLOCK dances in accounting
> > > path.
> > >
> > > Note that hardclock(9) still increments p_{u,s,i}ticks without holding a
> > > lock. I doubt it's worth doing anything so this diff doesn't change
> > > anything in that regard.
> >
> > Updated diff:
> >
> > - Use struct assignment instead of timespecadd() to initialize
> > `tu_runtime', pointed out by visa@.
> > - Do not use mtx_enter(9)/leave(9) in libkvm's version of FILL_PROC(),
> > pointed out by guenther@ and lteo@.
> >
> > Oks?
>
> I fear that what was committed isn't quite right:
Yes. I just reverted the diff. The problem is that hardclock(9) can be
called with any mutex held. So as long as schedclock() needs to grab
the SCHED_LOCK() to update `p_estcpu' and `p_usrpi' we'll have lock
ordering problems.
I'm already working on a fix (:
