head -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .?

[Justin Hibbits]

On Mon, 4 Mar 2019 19:43:09 -0800
Mark Millard via freebsd-ppc <freebsd-ppc at freebsd.org> wrote:

> [It is possible that the following is tied to my hack to
> avoid threads ending up stuck-sleeping. But I ask about
> an alternative that I see in the code.]
> 
> Context: using the modern powerpc64 VM_MAX_KERNEL_ADDRESS
> and using usefdt=1 on an old Powermac G5 (2 sockets, 2 cores
> each). Hacks are in use to provide fairly reliable booting
> and to avoid threads getting stuck sleeping.
> 
> Before the modern VM_MAX_KERNEL_ADDRESS figure there were only
> 2 or 3 bufspacedaemon-* threads as I remember. Now there are 8
> (plus bufdaemon and its worker), for example:
> 
> root         23   0.0  0.0     0   288  -  DL   15:48     0:00.39
> [bufdaemon/bufdaemon] root         23   0.0  0.0     0   288  -  DL
> 15:48     0:00.05 [bufdaemon/bufspaced] root         23   0.0
> 0.0     0   288  -  DL   15:48     0:00.05 [bufdaemon/bufspaced]
> root         23   0.0  0.0     0   288  -  DL   15:48     0:00.05
> [bufdaemon/bufspaced] root         23   0.0  0.0     0   288  -  DL
> 15:48     0:00.05 [bufdaemon/bufspaced] root         23   0.0
> 0.0     0   288  -  DL   15:48     0:00.05 [bufdaemon/bufspaced]
> root         23   0.0  0.0     0   288  -  DL   15:48     0:00.07
> [bufdaemon/bufspaced] root         23   0.0  0.0     0   288  -  DL
> 15:48     0:00.05 [bufdaemon/bufspaced] root         23   0.0
> 0.0     0   288  -  DL   15:48     0:00.56 [bufdaemon// worker]
> 
> I'm sometimes seeing processes showing [*buffer arena] that
> seemed to wait for a fairly long time with that status, not
> something I'd seen historically for those same types of
> processes for a similar overall load (not much). During such
> times trying to create processes to look around at what is
> going on seems to also wait. (Probably with the same status?)
> 

Hi Mark,

Can you try the attached patch?  It might be overkill in the
synchronization, and I might be using the wrong barriers to be
considered correct, but I think this should narrow the race down, and
synchronize the timebases to within a very small margin.  The real
correct fix would be to suspend the timebase on all cores, which is
feasible (there's a GPIO for the G4s, and i2c for G5s), but that's a
non-trivial extra work.

Be warned, I haven't tested it, I've only compiled it (I don't have a
G5 to test with anymore).

- Justin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: powermac_tb_sync.diff
Type: text/x-patch
Size: 914 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20190306/fddf6053/attachment.bin>