Well that was fun… NOT!
In a comment on an open discussion thread, I’d mentioned I was using the Pine64 as a “Daily Driver” for a while to see if it was suitable (in the PineBook) as my tablet / mobile stuff replacer. The answer is more or less “almost”, maybe.
It plays videos OK in a Theater Mode on Chromium (FireFox in small size only). That was with 2 tabs open. Memory use was about 1/2 of the GB (a bit more in FFox). I can live with that.
Then, since Alex Jones is busy being attacked and deplatformed, I decided to just open a tab to his website and run a video there. I’d been doing this on the Roku (partly just as a ‘thumb in the eye’ of the SILENCE!!! crowd) but he got nuked there, to. So I’m setting up to have it just run on a browser… but on the Chromebox it would run for about an hour then get a framing error of some sort. OK, I’ve got lots of other hardware… (I won’t mention that I have zero such errors on any OTHER site…)
So I launched his front page an in about 2 minutes the whole system turned to slow-mo mollasses in January in Fargo S.D.
WT? It looked like it was locked up hard, but every so often the “htop” panel would change a little. OK, we’re in some kind of thrash lock. I clicked on htop (slowly nursing the mouse over, one inch of mouse and wait a minute to see where the cursor moves, one inch, move…) and waited. It showed ALL of the GB of memory was used and ALL of the 480-ish MB of SWAP was used. OK, we’ve run out of swap. The OS is trying desperately to load everything and is busy just playing with swap and trying not to misplace its mind. Got it.
Clicking on the “close box” for Chromium, or for the individual tabs didn’t do anything. Likely because too much of the browser was swapped out.
Now, one thing I typically do is have a “root window” open. I’m usually playing with some kind of system stuff anyway, and it’s an old habit from being the System Police to be ready to kill any rogue process or user or “whatever” threatens the system. Lucky for me it was just visible at the bottom of the screen. After about 3 minutes of inching the cursor down to it, click. Then typed “halt” and carriage return. Then waited. After a few more minutes, the command showed up and the system halted.
FWIW, on the Odroid XU4 I have the same InfoWars Browser window open and I’ve filled all of the 2 GB of memory along with 64 MB of swap space. Make sure you have more than 2GB total of memory + swap. I have 3.5 GB now on the Pine64; 4 GB on the XU4. Page Weight is reaching a whole ‘nother level… So “note to self”, for that PineBook get extra memory… if possible. Hitting the wrong web page can put you in thrash lock.
Quasi Fixing It
Looking into things, after a reboot… it looks like Armbian Ubuntu puts all of swap into a compressed temp disk image in RAM. Yeah, to swap out of RAM you use a RAMdisk… This avoids write latency to the uSD card and wear on the uSD card and it effectively turns memory usage into CPU usage (for the compression / decompression), so “I get it”. But really? NO provision for an overflow area out of RAM entirely?
So I’ve added a 2 GB swap area on the uSD card. Using it first, the YouTube music video gets a bit more “choppy”, but Alex didn’t crash my system anymore. I’m now going to change the priority so that the uSD swap is used as a ‘backing store’ (i.e. lower priority) behind the RAMdisk. Given the thermal limiting I saw on videos in larger screen sizes, this might work well (with a heat sink) or it might be better to reduce that CPU use by having the uSD swap come first.
In doing the swap setup, I discovered (of course…) that “SystemD Does It Different”. Sigh. Now it has taken over swap and swap administration too. The cancer spreads… I’m not yet at the point of converting this install to Devuan ( I want a bit more performance information first) mostly because the PineBook is likely to have special drivers that may or may not be happy with Devuan. I might end up stuck with a systemD system for a while if I buy one. (another “Dig Here”…)
So here’s the Tech Talk part:
As root, inspecting where swap presently is. Oh, 4 small ramdisks of about 125 MB each.
root@pine64:/# swapon -s Filename Type Size Used Priority /dev/zram1 partition 125292 0 5 /dev/zram2 partition 125292 0 5 /dev/zram3 partition 125292 0 5 /dev/zram4 partition 125292 0 5
Then adding a swap file (as I don’t have a Real Disk partition…) On the “someday” list is to shrink the filesystem on the uSD card and add a Linux Swap partition. Yes, I know a swapfile is just as good… I just like to see my swap space called out when I do things like gparted or look at fstab. Knowing the device it is on is helpful sometimes (especially when you move devices around a lot like I do). Normally I put swap on a USB real disk too. In this case I’m not doing that as the intent is to model what the PineBook experience will likely be.
I typically name this file SWAPFILE. So the first step is to see if it will have a name conflict:
root@pine64:/etc# ls S*
ls: cannot access ‘S*’: No such file or directory
OK, good to go. Now we make a 2 GB file, make it read / write only for Root, make a swap format space in it, and turn it on:
root@pine64:/etc# fallocate -l 2G SWAPFILE root@pine64:/etc# ls -l SWAPFILE -rw-r--r-- 1 root root 2147483648 Feb 18 18:05 SWAPFILE root@pine64:/etc# chmod 600 SWAPFILE root@pine64:/etc# mkswap SWAPFILE Setting up swapspace version 1, size = 2 GiB (2147479552 bytes) no label, UUID=a6a94d05-e5b7-4010-89bb-95438d60636a root@pine64:/etc# swapon SWAPFILE
Did it work?
root@pine64:/etc# swapon -s Filename Type Size Used Priority /dev/zram1 partition 125292 0 5 /dev/zram2 partition 125292 0 5 /dev/zram3 partition 125292 0 5 /dev/zram4 partition 125292 0 5 /etc/SWAPFILE file 2097148 0 -1
Yes, but with a “don’t use me unless desperate” priority setting. OK for a backing store, not so good for testing it… So I decided to make it higher priority for testing, and put the mount of it as swap in the /etc/fstab place where it has always been.
Being just a tiny bit (justifiably…) paranoid that SystemD had screwed this up too, I did a quicky web search that turned up “Yes! Screwed the Pooch Here TOO!”…
“Why? Don’t ask why. Down that path lies insanity and ruin. -E.M.Smith” It is just what Pottering does. There is a high dick-with factor in that one.
Manual page here has the gory details.
A unit configuration file whose name ends in “.swap” encodes information about a swap
device or file for memory paging controlled and supervised by systemd.
This man page lists the configuration options specific to this unit type. See
systemd.unit(5) for the common options of all unit configuration files. The common
configuration items are configured in the generic [Unit] and [Install] sections. The swap
specific configuration options are configured in the [Swap] section.
Additional options are listed in systemd.exec(5), which define the execution environment
the swapon(8) binary is executed in, in systemd.kill(5), which define the way the these
processes are terminated, and in systemd.resource-control(5), which configure resource
control settings for these processes of the unit.
Swap units must be named after the devices or files they control. Example: the swap device
/dev/sda5 must be configured in a unit file dev-sda5.swap. For details about the escaping
logic used to convert a file system path to a unit name, see systemd.unit(5).
All swap units automatically get the BindsTo= and After= dependencies on the device units
or the mount units of the files they are activated from.
Swap units with DefaultDependencies= enabled implicitly acquire a Conflicts= and an After=
dependency on umount.target so that they are deactivated at shutdown, unless
DefaultDependencies=no is specified.
Additional implicit dependencies may be added as result of execution and resource control
parameters as documented in systemd.exec(5) and systemd.resource-control(5).
BLAH Blah blah blah BLAH blah Blah….
The only bit that matters is that they left a hook to let you do it by the “old way” of one easy line in the /etc/fstab file
Swap units may either be configured via unit files, or via /etc/fstab (see fstab(5) for
details). Swaps listed in /etc/fstab will be converted into native units dynamically at
boot and when the configuration of the system manager is reloaded. See systemd-fstab-
generator(8) for details about the conversion.
If a swap device or file is configured in both /etc/fstab and a unit file, the
configuration in the latter takes precedence.
So I can ignore that crap unless someone else has not ignored it. OK… I guess maybe he’s starting to hear the folks who have complained that changing how everything is administered is a Royal Pain ita and Breaks Things.
I can live with that (barely)… So I edited the file and added the one line in bold at the bottom:
root@pine64:/etc# cat /etc/fstab UUID=f56fc0fc-5c24-4529-86fa-d3819850ed05 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 /etc/SWAPFILE none swap sw,pri=6 0 0
then rebooted. Now the uSD is one unit of priority ahead of the RAMdisk. I did this for testing and will change that pri= to a 1 after this, so ramdisk will come first and then the uSD space. Then performance ought to be like it was before while the system won’t hang when a Huge Fat page comes along.
Here’s the present swapon output:
root@pine64:/# swapon -s Filename Type Size Used Priority /etc/SWAPFILE file 2097148 165.3M 6 /dev/zram1 partition 125292 0 5 /dev/zram2 partition 125292 0 5 /dev/zram3 partition 125292 0 5 /dev/zram4 partition 125292 0 5
More useful information on swap and tuning here:
Includes things about adjusting swappiness and cache pressure settings.
Once again my loathing of SystemD has been reinforced and extended. Swap worked FINE. It wasn’t broken, don’t “fix” it.
For any 1 GB memory system, you will need to check where any configured SWAP actually goes. If it is all ramdisk, and too small, add some more space so your system doesn’t go into thrash lock on SWAP.
This demonstrates that “limited hardware” is limited, and limiting. You can only trade one part for another if you have some part in excess. (RAM, CPU, Disk I/O swap, etc.).
It’s good to keep a “reboot me” window open where you can slide a mouse over it and just type “halt”.
If at all possible, get more than 1 GB of memory in systems where you expect to visit random web pages. Some can kill a 1 GB system (or at least wound it horribly).
With that, I now return you to your regular programming…