Boot a frugal install using the lowest possible amount of RAM memory

[bigpup]

You can run a frugal install using the lowest amount of memory possible.
Boot using the boot option pfix=nocopy
Puppy boots, but does not load the different SFS files into memory.
Only loads what is needed for Puppy to run and provide a working desktop.
Starting programs will be slower, but after the program loads into memory, it will run normally.

Example boot menu entry:
menuentry "fossapup64 9.5 - Don't copy SFS files to RAM" {
linux /vmlinuz pfix=nocopy,fsck pmedia=usbflash
initrd /initrd.gz

[Clarity]

The same parm(s) can be used to boot any 2020-2021 WoofCE PUP via its ISO.

Use the instructions scattered on how to set up the folder for ISOs and SG2D will find and boot with the PUP's parms via UEFI or BIOS.
This yields the EXACT results without the need to setup a Frugal: Performance is identical, behavior is identical without the need to take up space that FRUGAL requires. Other benefits exist too.

FYI

[user1111]

When I boot to ram I like to have a puppy sfs that is the most tightly compressed, xz high compression type choice. When instead I boot with the nocopy to ram type alternative the sfs filesize is much less relevant and I go with the lz4 compression choice for its speed of decompression.

With the former you might end up with a 333MB sfs file copied into ram, and if all of that is accessed during a session that might eat another 1GB of ram (cache/swap) being used i.e. assuming a 3:1 type compression. Maybe 1.3GB of ram being used, just for files.

For the latter the compression might be more like 2:1, but where reading 100MB from disk where decompressed = 200MB of data/program can be faster than having read 200MB of non compressed data/program from disk i.e. lz4 decompression speeds can be faster than disk read speeds (especially when multiple cores are being used). An where once booted perhaps only 250MB of ram is being used.

Much is subject to whether your kernel has been compiled to support xz, lz4 (whatever) compression methods, some distro/kernel providers opt to just support gzip, all depends upon how the kernel was compiled. More often you can run zcat /proc/config.gz in a terminal window to see what settings were used to compile a kernel. If that contains something like SQUASHFS_LZ4=y and HAVE_KERNEL_LZ4=y entries, then lz4 compressed sfs's may very well be supported.

To convert a sfs I tend to uncompress it, i.e. on a ext type partition/folder that has plenty of free space ...

unsquashfs puppyxxx.sfs

that creates a squashfs-root folder of the content, and then create another sfs using the desired compression choice

mksquashfs squashfs-root puppyxxx.NEW.sfs -comp lz4

and then remove the squashfs-root folder when done
rm -rf squashfs-root

and then that original puppyxxx.sfs can be swapped out (renamed) for the new version, before rebooting into the new version. Best done on a system with multiple boot choices so if it doesn't work you can boot into a working system and rename things back to as they were before. And of course after having made backups of your savefile/folders/data.

I used to boot looking to load everything into ram such that the HDD could be isolated after bootup for security reasons. Subsequently I moved over to booting with the nocopy type style in order to minimise the amount of ram used, in order to leave more ram available for concurrent dual booting i.e. where I use kvm/qemu to boot another system, so that both systems are available at the same time. I primary boot Fatdog, and then kvm/qemu boot OpenBSD (I prefer to use OpenBSD for browsing for its better security). Note that in Fatdog the boot command differs to that of Puppy systems i.e. it uses a 'basesfs=direct:...' parameter instead of 'basesfs=ram:...' parameter and where the humongous sfs has been separated out (its all documented in the Fatdog help, search for 'humongous').

Using a larger but faster lz4 compressed puppy sfs will tend to see programs start up quicker the first time than if gz or xz compressed puppy sfs was used. But once loaded once, more often the system will keep things cached such that subsequent starting of a program will be little/no different - as whichever way the program will already be in cache (ram), so no difference is speed whether booted using copy to ram, nocopy or whether the sfs was compressed using xz, gz or lz4.

[user1111]

Use the instructions scattered on how to set up the folder for ISOs and SG2D

SG2D (booting using a iso) ... viewtopic.php?f=85&t=387

[Clarity]

... so no difference is speed whether booted using copy to ram, nocopy or whether the sfs was compressed using xz, gz or lz4.

Performance to user IS what we strive toward.

[wiak]

But once loaded once, more often the system will keep things cached such that subsequent starting of a program will be little/no different - as whichever way the program will already be in cache (ram), so no difference is speed whether booted using copy to ram, nocopy or whether the sfs was compressed using xz, gz or lz4.

Above is assuming the system has enough excess RAM available for either copy2ram, or cache. If cache insufficient pages will be dropped or swapped-out and need to be re-fetched. On my 4GB system, I do indeed find caching works well for most of the activities I undertake, and I never copy2ram since I like to keep as much RAM free as possible. Also, I use a pretty fast SSD drive so the old issues related to slow mechanical hard drives isn't such a huge deal anymore with that setup.

[MochiMoppel]

@bigpup May I suggest that you move this thread to the "Boot" subforum? It's too important to get lost in the unsorted flood of Tips & Tweaks.

[amethyst]

Agree that if one use the pfix=nocopy parameter it is highly recommended to use a faster decompression method (stay away from xz in this case). I have an old machine so run the new puppys with older kernels. I have re-compressed all my sfs files with gzip compression instead and the performance is notably faster and less memory intensive. I'm aware that lz4 is even faster (but compression ratio poor) if you use a new kernel that support it but for me gzip remains an acceptable compromise between compression ratio (which is okayish) and speed.

[user1111]

I'm aware that lz4 is even faster (but compression ratio poor) if you use a new kernel that support it but for me gzip remains an acceptable compromise between compression ratio (which is okayish) and speed.

For info ...
mksquashfs squashfs-root some.sfs -comp lz4 -Xhc
(i.e. add the -Xhc switch) compresses tighter, mildly slower to compress than straight lz4, no difference in decompression speeds, tighter compression.