I’ve got 64 GB of RAM and would like to force cargo to dump build artifacts into it. So basically the target/
directory should end up there.
Unless I’m mistaken RAM is much faster than SSDs and since I do rebuild quite often, it would save some R/W cycles on my SSD and allow faster file access.
I do jot mind doing a full rebuild every morning
Solution:
These 2 comments gave me the best indication how to do it: cargo ramdisk and build.target-dir config options.
Would be great if cargo had a build.target-dir-prefix
though. One could set and env var CARGO_TARGET_DIR_PREFIX
and point it at /dev/shm
or /tmp
if it’s a tmpfs and every rust project would have its artefacts end up in RAM.
On Linux you can use tmpfs
/tmp
is stilltmpfs
here, but I prefer this (below) nowadays for usages that are not typical/tmp
usages:n=$(cat /sys/class/zram-control/hot_add) echo zstd > /sys/block/zram${n}/comp_algorithm # change that if you like echo 8G > /sys/block/zram${n}/disksize # larger disk probably needed for /target mkfs.ext4 -O '^has_journal' -L TMPZ -m 0.001 /dev/zram${n} # discard is important for auto-trimming mount -o noatime,discard /dev/zram${n} /tmpz chmod 777 /tmpz chmod +t /tmpz rm -rf '/tmpz/lost+found'
This is a part of my zram devices initialization script, a bunch used for swap as usual, then ending with this.
modprobe zram num_devices=0
works if one likes tohot_add
all devices.From zram you get a block device with builtin compression. From ext4, you still get features like creation time, truncate and fallocate support, …etc. And with discard, ram usage will be limited to used space (like tmpfs). Also ext4 is used without a journal to avoid what would be useless overhead in this use-case.
As other already mentioned you can mount a RAM disk yourself to where the target folder would be placed. Alternatively you can change where cargo places its artifacts to somewhere you already have a ram disk mounted, e.g. /tmp
https://doc.rust-lang.org/cargo/reference/config.html#buildtarget-dir
Linux uses all free RAM as cache automatically.
Your build artefacts will already be in RAM as the kernel will utilise any spare for the block cache. The block cache is evicted using a least recently used (LRU) basis when the system is under memory pressure. Using ram based filesystems is basically bypassing the kernel and reducing it’s flexibility to make the best use of spare RAM in the system.
Agreed. Take a look at the cachestat tool to measure how well the page cache is working for cargo builds.
https://www.brendangregg.com/blog/2014-12-31/linux-page-cache-hit-ratio.html
Maybe use a RAM based fs? Some distros mount
/tmp
as tmpfs into the RAM. You can look into that.Ramdisk?
I have used cargo ramdisk before with success.