Re: Armv7 (rpi2) getting stuck in buildworld for -current

On Sun, May 14, 2023 at 08:12:23PM -0700, Mark Millard wrote:
> 
> I'm unsure if you have well avoided having any tmpfs based
> space or the like that would compete for RAM and use some
> of the RAM+SWAP. In the low RAM environments, I avoid such
> competition and use UFS to exclusion.
>
 
No use of tmpfs, the line in /etc/fstab is commented out
I've commented out the changes to /boot/loader.conf related
to virtual memory as well. All were introduced in response
to slow flash storage, it looks like they're not needed with
mechanical disks and at least sometimes counterproductive.
Since these changes there have been no communications losses.

> I'll note that causing swap space thrashing can make builds
> take longer. "Thrashing" is not directly the space used but
> the frequency/backlog of swap space I/O. I always avoided
> configurations that thrashed for notable periods of time,
> via using -j given that I'd already avoied RAM+SWAP
> competition. But thrashing is also tied to the likes of
> spinning rust vs. various, for example, NVMe USB media. It
> is probably generally easier to make spinning rust thrash
> for notable periods. I'd also avoided spinning rust.

I can't help but wonder if the dominant I/O bottleneck
on a Pi2 or Pi3 isn't the usb subsystem. With none-too-fast
5400 rpm mechanical disks there are no console warnings about
swap, despite obvious memory pressure (high swap use, high
idle percentage). Most of the time one thread is eventually 
given elevated priority and the overload is worked through. 

This morning a Pi3 was found seemingly jammed. All four threads 
were about 500MB in size, all had priority 20 with about 1% WCPU. 
No console messages warned of swap pressure, but the system was stalled.
Occasionally one thread would get priority 21, but quickly reverted 
to 20 so the jam didn't clear. After poking around interactively
reading man pages one thread got priority 135 and progress resumed.   

For the moment it appears that, at least when using mechanical
disks, no adjustments to the VM  configuration are needed on
either Pi2 or Pi3. Random user interaction via keyboard seems
helful to break priority ties when swap use becomes intense.

Might it be possible for a script to detect thrashing and stimulate
similar behavior?

Thanks for reading!

bob prohaska