increasing swapfile space on the raspberry pi 4

Update 20 April 2020

This post’s original recommendation only works with a Raspberry Pi with 1GiB of memory. For a Pi with 2 or 4GiB, the swap file size is clamped to 2GiB, as if CONF_MAXSWAP were uncommented and active. Since the 2GiB Raspberry Pi 4 is replacing the 1GiB version, then the original post does not apply at all. For a Raspberry Pi with 2GiB or more memory, you need to:

  • Comment out CONF_SWAPFACTOR (line 19)
  • Uncomment CONF_SWAPSIZE (line 15) and set it to the size you need in MiB.
    • For example, CONF_SWAPSIZE=4096 will produce a swap file size of 4GiB.
  • Uncomment CONF_MAXSWAP (line 25) and set it to the maximum size you want your swap file in MiB.
    • For example, CONF_MAXSWAP=4096 will work with CONF_SWAPSIZE to produce your 4GiB swap file.

This is what I had to do to create a 4GiB swap file on my Raspberry Pi 4B with 4GiB of memory.

Original Post

Raspbian desktop with LXTerminal running htop and Chromium with multiple open tabs

If you’re going to use the Raspberry Pi 4 as a basic personal computer, meaning lots of open applications with Chromium in the mix with its multiple open tabs, then you’re going to have to adjust certain aspects of Raspbian’s operation to make it behave the way you want it to. A key aspect is swap space.

Swap space is specialized disk space to support the operation of virtual memory. Virtual memory is a memory management technique where the operating system (in this case Raspbian) will write out to disk the contents of memory that are not being used when other active applications demand more memory than is physically available. That means if you have a Raspberry Pi with only 1GB of physical memory, and you have launched a number of applications with, for example, a combined demand of 1.2GB of physical memory, then Raspbian (based on Debian Linux) will determine what applications can be idled and what portions of physical memory associated with those applications are being used at the moment and write those memory portions out to a disk structure called swap, freeing up enough memory for the newly running application to execute. When idled applications need to run, then their memory, if swapped out, will be swapped back in before they are allowed to run again, and if there’s still not enough to support everything, then new idle candidates will have their memory swapped out to disk. It sounds complicated, but it’s been honed now for decades and works very well. That sounds like a wonderful system as long as you have enough swap (disk) space.

The problem is that stock Raspbian installs with only 100M defined for swap, and as you’ll note in the screenshot above, I’ve exceeded that default amount by 42MB for a total (at that point in time) of 142MB just by having an LXTerminal open with two tabs and Chromium open with seven tabs. Something had to be adjusted before this happened because when swap is filled up (exhausted in the parlance) then applications begin to crash. To avoid this, I modified a swap configuration file as soon as I had Raspbian installed. That file is /etc/dphys-swapfile.

What you need to do is execute ‘sudo vi /etc/dphys-swapfile’ (if you don’t know vi, then use another editor you’re more comfortable with):

# /etc/dphys-swapfile - user settings for dphys-swapfile package# author Neil Franklin, last modification 2010.05.05# copyright ETH Zuerich Physics Departement#   use under either modified/non-advertising BSD or GPL license# this file is sourced with . so full normal sh syntax applies# the default settings are added as commented out CONF_*=* lines# where we want the swapfile to be, this is the default#CONF_SWAPFILE=/var/swap# set size to absolute value, leaving empty (default) then uses computed value#   you most likely don't want this, unless you have an special disk situationCONF_SWAPSIZE=# set size to computed value, this times RAM size, dynamically adapts,#   guarantees that there is enough swap without wasting disk space on excessCONF_SWAPFACTOR=2# restrict size (computed and absolute!) to maximally this limit#   can be set to empty for no limit, but beware of filled partitions!#   this is/was a (outdated?) 32bit kernel limit (in MBytes), do not overrun it#   but is also sensible on 64bit to prevent filling /var or even / partition#CONF_MAXSWAP=2048

On line 15, remove any value (the default is actually set to 100 in spite of what the comment right above it says), also uncommenting line 19. Then reboot. The OS will determine the maximum for you during boot, which in my case was 1.7GB, instead of the fixed default of 100MB.

As a historical note I use to just change CONF_SWAPSIZE to 2048 (2GB) because I used the very old rule of thumb to have a swap space twice my physical memory. In my calculation I used the absolute total memory of the Raspberry Pi (1GB), which is why my value is a bit higher than what is shown above. It would appear to be the same formula that Raspbian uses. The value shown when automatically determined is a bit more exact. Actual available memory is the maximum installed minus video memory used, which is 872MB in this case. Multiplying available memory by two yields 1,744MB, or 1.7GB, the maximum swap space value shown by htop.

the pimoroni scroll:bit – some observations

scroll:bit plugged into micro:bit

I’ve had the Pimoroni scroll:bit for a little while now, and I’ve managed to work with it and get it to perform a number of straight-forward activities. I’m writing some observations and comments based on my successes using the device.

The scroll:bit is purpose built for use with the BBS micro:bit, which in turn is easily used with the Raspberry Pi by communicating with the micro:bit over USB. I’ve been using it with my Raspberry Pi as a simple CPU temperature readout, as you can read in my earlier post. Working on that temperature readout utility taught me how to communicate with the micro:bit and to use the micro:bit to communicate with the scroll:bit. It’s very straightforward and easy to understand (at least for me), and it’s very nice to use Python on both the Pi as well as on the micro:bit itself.

For more detailed control of the micro:bit and the scroll:bit, I use the Mu editor. It’s available in the Raspian repo via ‘sudo apt install mu-editor’. Once installed it’s very straightforward to start and use with the micro:bit and any devices attached to the micro:bit. For example:

The Mu editor is displaying a very simple program that lights up every one of the scroll:bit’s LEDs. The Mu editor is more than just a Python editor. It is capable of fully controlling the micro:bit, allowing the programmer to directly program the Micro Python application directly to the device. For even deeper delving, the Mu editor has a REPL capability where you can work directly with the Micro Python interpreter just like you can with regular Python REPL. That comes in real handy when you’re trying to debug a single statement, or just want to try out a one-line coding trick to see how it really runs. If you’re not familiar with the Mu editor then you should install it and give it a try. It will reward you quite well with its easy to learn, powerful capabilities.

from scrollbit import set_pixel, showbrightness = 32for row in range(7):for col in range(17):set_pixel(col, row, brightness)show()

The example application was written to turn on all the LEDs on the scroll:bit while running on the micro:bit, which is what the lead image shows. There’s hardly anything to the application. I used variables in the call to set_pixel() instead of raw values so that it’s obvious what each one of those variables do. LED brightness can vary from 0 to 255; I chose a low value of 32 to keep from blowing out the taking camera with extreme contrast between the LEDs and the rest of the area. When those LEDs are set to brightness level 255 they are very, very bright.

USB is an acronym for Universal Serial Bus. With the Raspberry Pi and these even smaller boards, that bus is a powerful way to weave all the tiny computers together into interesting combinations. The Raspberry Pi touts its GPIO pins and I2C/SPI connectivity, but USB is no less powerful. I look forward to doing more with the micro:bit as well as another device I have in my tool box, Adafruit’s Circuit Playground Express. All these devices are run with ARM M0 processors. They don’t run nearly as fast as the Raspberry Pi’s CPU, but then they don’t have to.

When I look at all I have to work with between these various devices, I think back on what I had to do 40 or so years ago starting out in embedded design. I would have given my right arm for any of this and its ease of use. Instead, the company I worked for had to spend tens of thousands of dollars for very special test equipment and a lab for me to test my designs in the performance of my job. It’s all quite amazing how much you can do today, for so very little expense, and ease of use.