On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > > [...]
> > > > Did you run a make build with that smr_barrier() in it and checked that
> > > > it
> > > > does not cause a slow down? I am sceptical, smr_barrier() is a very slow
> > > > construct which introduces large delays and should be avoided whenever
> > > > possible.
> > >
> > > I did build GENERIC.MP multiple times on a 4CPU sparc64 with the diff
> > > below, without noticeable difference.
> > >
> > > I'm happy to hear from sceptical performance checkers :o)
> >
> > On a reasonably fast amd64 box, this increases GENERIC.MP make -j6 build
> > time from
> > ~3m06s to ~3m44s, which seems a bit much to me.
>
> Do you know if this is due to an increase of %spin time?
It actually decreased %spin, and the total system cpu time used during the
build was
decreased from around 6m30s to around 5m15, so I think it's mostly the effect
of the
delayed wakeup of the SMR thread in smr_dispatch().
There's also this:
$ time sleep 1
0m01.11s real 0m00.00s user 0m00.00s system
>
> > Replacing smr_barrier() with smr_flush() reduces the overhead to a couple of
> > seconds, and it seems warranted here.
>
> Could you try the diff below that only call smr_barrier() for multi-
> threaded processes with threads still in the list. I guess this also
> answers guenther@'s question. The same could be done with smr_flush().
This removes the overhead, more or less. Are we only looking at unlocking
access
to ps_threads from within a process (not the sysctl or ptrace stuff)? Otherwise
this doesn't seem safe.
