Puppy Ram Use rev2: What gets loaded into ram and when?

[wizard]

This topic comes up often. What gets loaded into ram and when. Although this is not a concise answer, you should be able to use this table for a general understanding.

Puppy-Ram-Use-rev2.jpg (42.42 KiB) Viewed 406 times

You can also download it as this spreadsheet.

Puppy-Ram-Use-rev2.xls

(9 KiB) Downloaded 27 times

For a detailed descripition of these files see this post :
viewtopic.php?f=184&t=5818

wizard

[backi]

@wizard :

Simple and useful Summary ---------Was needed badly.

[mikewalsh]

Nice one, @wizard !

That's taught this old dog a coupla new things, an' all. Sweet.

Mike.

[mikeslr]

The last Row on the Table needs clarification:

"Installed applications | Save file/folder | y"

If by "installed applications" what is meant is applications installed, indexed by restarting-x but not yet Saved then it uses RAM but it's location is not in the Save files/folder. If it's been Saved, then it is in the SaveFile/Folder, which doesn't load into RAM on boot-up. In fact, unless Saved it would not exist anywhere on reboot.

It may be best just to delete that Row. If by installed what is meant is applications which have become part of the puppy_xxx.sfs, adrv_xxx.sfs, ydrv_xxx.sfs, then the rows relevant to those file-systems reveal its use of RAM.

[wizard]

@mikeslr

If it's been Saved, then it is in the SaveFile/Folder, which doesn't load into RAM on boot-up. In fact, unless Saved it would exist anywhere on reboot.

Yes, you are correct, will add note..

Thanks
wizard

[amethyst]

Not clear from that table but if it's pfix=nocopy, NONE, of the puppy sfs files are copied to RAM as far as I know. BTW and as a matter of interest - You can actually set which puppy sfs files will be copied or not (if it's not pfix=nocopy) by editing the init in initrd.gz. I've tried that some time in the past. Also - it's copied not loaded. The Puppy sfs files are all mounted/loaded at bootup nevermind if it's pfix=nocopy or not.

[wizard]

@amethyst

Good point, will add clarification on the next revision. There are a lot of nuances, but don't want to complicate it to much for a generalization.

Thanks
wizard

[amethyst]

@amethyst

Good point, will add clarification on the next revision. There are a lot of nuances, but don't want to complicate it to much for a generalization.

Thanks
wizard

vmlinuz and the init is always loaded into RAM so that's correct but Puppy sfs files can be copied or not. All puppy sfs files are mounted, just to clarify. Also - the critical Puppy system files will also always be loaded into RAM.

[wizard]

Puppy Ram Use rev2 is now available in the first post. Thanks to members who suggested improvements to the content.

wizard

[mikeslr]

Not clear from that table but if it's pfix=nocopy, NONE, of the puppy sfs files are copied to RAM as far as I know. BTW and as a matter of interest - You can actually set which puppy sfs files will be copied or not (if it's not pfix=nocopy) by editing the init in initrd.gz. I've tried that some time in the past. Also - it's copied not loaded. The Puppy sfs files are all mounted/loaded at bootup nevermind if it's pfix=nocopy or not.

The following may only be a clarification of the above.

AFAIK, how file-systems are managed depends on the instructions provided by initrd(.?z). Among those instructions are that when the boot-stanza contains the "nocopy" argument only those files necessary to provide a Menu-Listing and links to other files of applications in the 'Core' SFS --i.e. puppy_xxx,sfs-- will be copied into RAM. AFAIK, as generally written the 'nocopy' argument will have no effect upon the handing of 'alphabet.SFSes', e.g. fdrv.sfs, ydrv.sfs, zdrv.sfs, bdrv.sfs. These will be fully copied (compressed) into RAM. But if memory serves --a big IF-- and his post suggests amethyst has done some work in modifying initrd(.?z) which would prevent them from being fully copied.

p.s. I still think a valuable addition to Puppy would be the re-invention of the 'firmware-cutter' and by extension (or implication) a 'driver-cutter'. fdrv.sfs may be 'small' --40 Mb +/- -- but if the one provided lacks the firmware you need you may have to substitute one over 150 Mbs. The 'cutter' identified the firmware your computer actually needed and generated a new fdrv.sfs just containing those: a couple of Mbs. I don't recall if it similarly managed drivers.