Date: Wed, 17 May 2023 09:00:35 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org Subject: Re: Armv7 (rpi2) getting stuck in buildworld for -current Message-ID: <ZGT6I9%2BlYSJfdp6G@www.zefox.net> In-Reply-To: <A1CFA2DF-1D38-45E2-8A82-05E94FC29C90@yahoo.com> References: <ZGD/8CXbIFtCuiFF@www.zefox.net> <7758885B-3115-47F0-A453-1C010313D4B8@yahoo.com> <ZGF1mOJXTarXIAwZ@www.zefox.net> <A1CFA2DF-1D38-45E2-8A82-05E94FC29C90@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZGT6I9%2BlYSJfdp6G>