Adding a swapfile and doing some preparation for development is one of the first things to do after flashing a NVIDIA Jetson Development Kit. Looky here:
Background
Over the last couple of years, the software capabilities of the Jetson Development Kits have increased dramatically. JetPack does a great job of keeping track and installing the many software libraries and Jetson specific software packages and demos. However, this does come at a cost. Because the Jetson Development Kit has a relatively small “hard drive” and a limited amount of memory, sometimes development can get bogged down a bit because of lack of system resources.
Fortunately, there are work arounds. Some of the larger programs and applications out there, such as TensorFlow and ROS to name just a couple, require more memory to build than the Jetson has available. A good work around for this is to use what is called a swap file, which allows the Jetson to use disk space as virtual memory. We talked about this in an earlier article.
Also, sometimes we would like to reclaim some of that disk space used by the installed software and demos, and repurpose it for development. In the video, we show how to get rid of some of the low hanging fruit.
Getting to Work
The video was performed directly after flashing the Jetson using JetPack 2.3.1. JetPack installed:
- L4T 24.2.1
- CUDA 8.0
- cuDNN 5.1
which is need for the project that I’m currently working on. Other libraries and demos were also installed such as VisionWorks.
On the JetsonHacks account on Github, there is a repository named postFlashTX1 which contains some convenience scripts for creating a swap file and reclaiming some of the disk space from some applications that sometimes are not used on development machines.
Swapfile
In the video, a 250GB Samsung EVO 850 SSD is connected to the Jetson TX1. The SSD is formatted as ext4. In order to create a swap file:
$ sudo ./createSwapfile.sh -d [directory location] -s [size in gigabytes] -a
All of the arguments are optional. The default is for a 8GB swapfile to be created in the current directory. The -a flag indicates whether the swapfile should be automatically be loaded on boot. If the swapfile is to be loaded at boot time, make sure to set up the media that it is on so that it is available when the machine boots.
For the 4 GB Jetson TX1, a 8 GB swapfile is a good size. The rule of thumb for the swap file size is about 2X real memory size. Also, try to place the swapfile on external media that is as fast as possible. While you can place the swapfile on a USB stick or SD card, note that there will be a real performance hit when compared to placing it on a SSD.
Important Note
Setting up a swapfile on a SSD or other flash type memory can lead to wear of the device. Most current flash memory has a lifetime number of reads and writes it can perform, a busy swap file can consume a good chunk of those. Note that this is also true of hard drives. Newer SSDs have built in mechanisms to help distribute the “write wear”. As always, make backups of your drives and store them away.
In the video, the swap file is auto mounted when the machine boots. This is great for development, but afterwards you may want to disable that feature. To do so:
$ sudo gedit /etc/fstab
and comment out the line that does the ‘swapon’. Make sure to save the file, reboot and check to make sure that swap is off.
Also, you may want to be a little more hard core about your swap area. You can set aside a ‘swap partition’ and use that instead of a swap file. This approach may be faster because the swap area is set aside contiguously. This route is similar to setting up a swap file, but is beyond the scope of this article.
More stuff
The other convenience files in the repository do some more cleanup work.
$ ./uninstallLibreoffice.sh
Will remove the Libre Office suite from the machine. While these are useful tools, they may not be needed for a development machine.
$ ./uninstall_unity_scope.sh
Will remove a lot of the links which support desktop like activities, such as shopping.
Conclusion
This is just a general purpose rough cut to get started on getting the machine ready for development. Obviously the development environment needs to reflect the applications that are being built. However, more memory and some more disk space is a real fine way to start.
16 Responses
Thank you for the article.
After flashing, there are some .deb files.
Is it OK to delete them?
There are below folders and files in home dir
– cuda-l4t
– cudnn_samples_v5
– libvisionworks-nvxio-1.5.3.71n
– NVIDIA_CUDA-8.0_Samples
– OpenCV4Tegra
– PerfKit
– tegra_multimedia_api
– VisionWorks-SFM-0.88-Samples
– jetson_clocks.sh
– libvisionworks-nvxio_1.5.3.71n.debian.tar.gz
– libvisionworks-nvxio_1.5.3.71n.dsc
– libvisionworks-nvxio_1.5.3.71n.orig.tar.gz
– libvisionworks-nvxio_1.5.3.71n_arm64.changes
– libvisionworks-nvxio_1.5.3.71n_arm64.deb
– libvisionworks-nvxio-dev_1.5.3.71n_all.deb
– libvisionworks-repo_1.5.3.71n_arm64_l4t-r24.deb
– libvisionworks-sfm-repo_0.88.0_arm64_l4t-r24.deb
– libvisionworks-tracking-repo_0.84.0_arm64_l4t-r24.deb
– nv-gie-repo-ubuntu1604-6-rc-cuda8.0_1.0.2-1_arm64.deb
– tegrastats
I think some of them are only needed for installation just after flashing, but I’m not sure. Which of them can be deleted?
Can’t comment on each file, it depends on how you are using your machine. In general, folders that have ‘Samples’ in the name contain samples development code. The .deb files are the files used for installation; they may or may not be needed depending on what you are building. The remains folders tend to hold libraries and development tools. The other files tend to be executables or shell files that are used for development purposes.
You might want to make a backup of the files you are going to delete on a flash drive or SD card in case you need them later. Thanks for reading!
Thank you very much
Hi Jim
I did tired to follow this but instead of using a SSD I’m using an industrial SD card, but the OS is not mounting the SD card.
also I had noticed that once you create the swapfile did delete all the SD contents.
to reduce the risk of this deletion, I did create three partitions of my SD card
one for swap -> to have only one file for swap
I have it working now, Thanks
Good to hear!
hi, thanks for the great tutorials ! I have mounted an SSD as the root dir thanks to your other video. Is it a good idea to use the internal sd card as a swap file ? Otherwise, if I use the SSD what should I do differently from your tutorial ?
Thanks !
You should use the SSD to hold the swap file. You can use the same shell script shown in the video to create the swapfile. Thanks for reading!
Hi Kangalow,
Firstly, thanks for the great videos. I’m switching from a Rasperry Pi as companion computer on my Groundhog hexacopter to a TX2, and from Dronekit to ROS. These videos have been great to get me off, the ground, so to speak.
I would value your opinion as to whether a swap file is necessary for the TX2 as I think it has twice the capacity of the TX1. I am implementing the full ROS desktop gui and also full Tensorflow, as in your video.
Many thanks!
Thank you for the kind words. This sounds like a fun project!
If you are trying to compile Tensorflow on the device itself, you will more than likely need a swap file, it’s a little piggy when building. If instead you decide to install Tensorflow from a .whl file, you may not need one. Thanks for reading!
Hello,
Does this method work on JetPack 3.1+ ? Need swap file on JetPack 3.1, and mostly without re-compiling the kernel. Help me out here.
This method does not work for L4T 28.1 (JetPack 3.1).
For L4T 28.1, the kernel needs to be recompiled to enable swap memory. Please see:
https://jetsonhacks.com/2017/09/18/build-tensorflow-on-nvidia-jetson-tx1-development-kit/
Thanks for reading!
Hi Jim,
I have a TX1 with SSD drive.
In your previous video I followed your instructions and successfully copied the entire O/S from emmc to the SSD drive. I rebooted and everything was working fine.
I then followed your steps above to increase swap space. I used the createSwapfile.sh and it sucessfully created swap on / (root). Next the GUI Disks, I choose Edit mount Options, Turn on Automatic Mount Options (Mount at startup, Shower user inferface), Mount Point set to /, Identify As UUID= 342…
Click OK, rebooted, login as ubuntu, and tried to sudo.
then I see this issue:
$sudo
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the ‘nosuid’ option set or an NFS file system without root privileges?
I tried to su – root and I was not able to.
su: Authentication failure
Additional information on fstab & mount below.
Any help would be greatly appreciated.
Thanks in advance.
Steve
ubuntu@tegra-ubuntu:~/Downloads/postFlashTX1$ cat /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
//swapfile none swap sw 0 0
UUID=342c61ac-9dbf-41b8-a7b6-e4423a6bef41 / auto nosuid,nodev,nofail,x-gvfs-show 0 0
ubuntu@tegra-ubuntu:/etc$ mount
/dev/sda1 on / type ext4 (rw,nosuid,nodev,relatime,data=ordered)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type devtmpfs (rw,relatime,size=2033500k,nr_inodes=508375,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=409064k,mode=700,uid=1000,gid=1000)
/dev/mmcblk0p1 on /media/ubuntu/76ebd266-c20c-44cf-b254-93c287d40c00 type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
Hi Steve,
I’m not quite sure how to fix your issue. When you set up the SSD as root, it effectively auto-mounts the SSD. This article was written for a system that is running off the eMMC, and would need to make sure that the SSD is mounted before using it for swap memory.
By modifying the SSD mounting options, it looks like the system got pretty confused. You can try to boot from eMMC using a serial console and modify the stab file.
I don’t have a SSD but I have a SDCard. However following your process, it doesn’t work for the SDCard. Do you know the reason? Thanks.