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

[Mark Millard]

[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?)

/usr/src/sys/vm/vm_init.c has:

        /*
         * Allocate the buffer arena.
         *
         * Enable the quantum cache if we have more than 4 cpus.  This
         * avoids lock contention at the expense of some fragmentation.
         */
        size = (long)nbuf * BKVASIZE;
        kmi->buffer_sva = firstaddr;
        kmi->buffer_eva = kmi->buffer_sva + size;
        vmem_init(buffer_arena, "buffer arena", kmi->buffer_sva, size,
            PAGE_SIZE, (mp_ncpus > 4) ? BKVASIZE * 8 : 0, 0);
        firstaddr += size;

I wonder if the use of "BKVASIZE * 8" should track the
bufspacedeamon-* thread count and not just the mp_cpus count --or
if the bufspacedeamon-* thread count should track the mp_ncpus
count (and so be smaller for only 4 "cpus" in FreeBSD terms.)

Or may be  [*buffer arena] is inherent in having:
(Not from the time frame of having the [*buffer arena]
showing up, not even from after such. I've not managed
to see such figures during and I've not recorded any
after.)

real memory  = 17134088192 (16340 MB)
avail memory = 16385716224 (15626 MB)

hw.physmem: 17134088192
hw.usermem: 15232425984
hw.realmem: 17134088192

Virtual Memory:		(Total: 455052K Active: 413888K)
Real Memory:		(Total: 64736K Active: 62508K)
Shared Virtual Memory:	(Total: 56264K Active: 15232K)
Shared Real Memory:	(Total: 16416K Active: 14204K)
Free Memory:	14022736K

vm.kmem_size: 5482692608
vm.kmem_zmax: 65536
vm.kmem_size_min: 12582912
vm.kmem_size_max: 13743895347
vm.kmem_size_scale: 3
vm.kmem_map_size: 414158848
vm.kmem_map_free: 5068533760

vfs.bufspace: 1397690368
vfs.bufkvaspace: 559185920
vfs.bufmallocspace: 0
vfs.bufspacethresh: 1680538825
vfs.buffreekvacnt: 1007
vfs.bufdefragcnt: 0
vfs.buf_pager_relbuf: 0



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)