Page 1 of 1

.sfs ram usage

Posted: Tue Dec 28, 2021 3:46 am
by JASpup

A user here estimated loading a .sfs might take up 10mb of ram. It seems like it would be less.

Is there a way to garner an accurate amount of ram usage by loading .sfs?


Re: .sfs ram usage

Posted: Tue Dec 28, 2021 2:59 pm
by Feek

Hello JASpup,

do you mean loading sfs "on-the-fly"?

Simple way in terminal:

before loading a .sfs file

Code: Select all

free -m > sfs_mem01.txt

after sfs load

Code: Select all

free -m > sfs_mem02.txt

then compare the values in the .txt files.

As I understand it, the load of a sfs doesn't take much ram space.
But the primary reason why to load a sfs is to run the sfs application and this will require appropriate space.
So the value of ram for sfs loading itself is not so important IMO.


Re: .sfs ram usage

Posted: Tue Dec 28, 2021 3:40 pm
by mikeslr

That may have been my estimate. 'up to' sounds like my qualification. If so, it was based on my hazy recollection of exploring the effect on RAM using different vehicles for using an application: installing pets, loading SFSes, and using portables. I was not aware of the code Feek offered above. Nor at that time aware that restarting-x cleared RAM. So had to do a lot of rebooting and usin pupsys-info: much more time and labor consuming.
The application being used was LibreOffice, then a 175Mb +/- SFS but requiring 500 +/- space in a SaveFile or hard-drive as a (decompressed) portable. But when an SFS was loaded --but neither it nor a document under it opened-- about 10 Mbs of RAM was used. You know, of course, that LibreOffice is a suite of applications: just SFS loading it creates multiple entries on the Menu requiring multiple files and symbolic links. It was chosen as a 'test-case' just because of my expectation that would require a lot of RAM.
How much initial RAM may depend on the size and structure of the application, itself. But don't depend on my assumptions. Explore the effects yourself. Pick some applications likely to be RAM intensive; and some likely not to be. Let us know.


Re: .sfs ram usage

Posted: Wed Dec 29, 2021 12:51 am
by JASpup
Feek wrote: Tue Dec 28, 2021 2:59 pm

So the value of ram for sfs loading itself is not so important IMO.

I appreciate the info and will try it.

The value of ram loading .sfs is very important. That's why we do it. If ram were not an issue we'd just copy entire .sfs to ram like the alphabet drives.

If you have .sfs sitting on static media, be it 2mb or 200mb, it is helpful to know how much ram loading those .sfs takes up.


Re: .sfs ram usage

Posted: Wed Dec 29, 2021 1:25 pm
by Feek
JASpup wrote: Wed Dec 29, 2021 12:51 am
Feek wrote: Tue Dec 28, 2021 2:59 pm

So the value of ram for sfs loading itself is not so important IMO.

I appreciate the info and will try it.

The value of ram loading .sfs is very important. That's why we do it. If ram were not an issue we'd just copy entire .sfs to ram like the alphabet drives.

If you have .sfs sitting on static media, be it 2mb or 200mb, it is helpful to know how much ram loading those .sfs takes up.

Our ways of using sfs files probably slightly differ.

I use the applications as sfs's mostly temporarily.
In other words I load it only when I need it, then launch the application added by sfs-load and when everything done I usually unload the sfs.

Hence the statement that the ram usage of the sfs-load itself (without running the app) is not so important.


Re: .sfs ram usage

Posted: Wed Dec 29, 2021 1:55 pm
by amethyst

I ran the free command and checked the used memory reported. I then loaded Seamonkey sfs on the fly immediately and ran the free command again. The memory usage reported increased by less than 2MB. I then repeated the test loading Chromium. Basically the same reading. I then loaded a very small sfs with the same result. So it seems to be less than 2MB. This may of course be a crude way of testing and inaccurate but it's the best I know. Tested with Bionic 32.


Re: .sfs ram usage

Posted: Wed Dec 29, 2021 2:20 pm
by JASpup
Feek wrote: Wed Dec 29, 2021 1:25 pm

Our ways of using sfs files probably slightly differ.

I use the applications as sfs's mostly temporarily.
In other words I load it only when I need it, then launch the application added by sfs-load and when everything done I usually unload the sfs.

Hence the statement that the ram usage of the sfs-load itself (without running the app) is not so important.

I go either way. I use browsers all the time by .sfs, and an app like LibreOffice temporarily. I copied an unsquashed browser into spot because when you have a lot of ram you do not notice, but on low-spec machines it matters.

It can become an understanding when trying to figure out how to best set-up your system, and a general ethic of efficiently managing system resources.

If you asked a lay user what's going on, they wouldn't have the foggiest. Taking compressed archives and spreading them across your system directories that are probably just in ram isn't everyday computing for most people. The designers want those archives sitting in the first directory of the partition for safety, but they don't need to be there. This is why it is important they are understood.


Re: .sfs ram usage

Posted: Wed Dec 29, 2021 2:29 pm
by JASpup
amethyst wrote: Wed Dec 29, 2021 1:55 pm

This may of course be a crude way of testing and inaccurate but it's the best I know. Tested with Bionic 32.

Reads useful to know. Crude is a start.

In Redmond World our configs are sitting on static media and rarely get cleared, right.

Should we necessarily put ours in ram on low spec machines, or maybe wherever we have the most discretionary storage. Then clear those on boot and maybe not our cache which is going to be high data images and whatnot, but not much privacy data.

I have browser 'routines' but still have not set up my machines for fluid use. I don't like the passive user way and being too technical about it probably isn't the best either.


Re: .sfs ram usage

Posted: Wed Dec 29, 2021 3:49 pm
by amethyst

Less than 2MB per sfs loaded, just to be clear. Best time to check would probably be first thing after boot to desktop (also I think booting with the nocopy parameter may be better for this test).


Re: .sfs ram usage

Posted: Wed Dec 29, 2021 9:30 pm
by Phoenix
JASpup wrote: Wed Dec 29, 2021 2:20 pm
Feek wrote: Wed Dec 29, 2021 1:25 pm

Our ways of using sfs files probably slightly differ.

I use the applications as sfs's mostly temporarily.
In other words I load it only when I need it, then launch the application added by sfs-load and when everything done I usually unload the sfs.

Hence the statement that the ram usage of the sfs-load itself (without running the app) is not so important.

I go either way. I use browsers all the time by .sfs, and an app like LibreOffice temporarily. I copied an unsquashed browser into spot because when you have a lot of ram you do not notice, but on low-spec machines it matters.

It can become an understanding when trying to figure out how to best set-up your system, and a general ethic of efficiently managing system resources.

If you asked a lay user what's going on, they wouldn't have the foggiest. Taking compressed archives and spreading them across your system directories that are probably just in ram isn't everyday computing for most people. The designers want those archives sitting in the first directory of the partition for safety, but they don't need to be there. This is why it is important they are understood.

Does it really matter though as to how much memory is used? The ram usage by the .sfs is VFS caching, which puppies' kernels will dump the cache at a "fair" rate with respect to pagecache and swapcache reclaim. This is controlled via vfs_cache_pressure in which setting to 0 will cause it to retain cache regardless of memory limits/pressure. Setting it higher than 100 (the default) will make it prefer to reclaim memory, but can cause performance impact because of the constant need to re-lookup.


Re: .sfs ram usage

Posted: Thu Dec 30, 2021 3:12 am
by JASpup
Phoenix wrote: Wed Dec 29, 2021 9:30 pm

Does it really matter though as to how much memory is used? The ram usage by the .sfs is VFS caching, which puppies' kernels will dump the cache at a "fair" rate with respect to pagecache and swapcache reclaim. This is controlled via vfs_cache_pressure in which setting to 0 will cause it to retain cache regardless of memory limits/pressure. Setting it higher than 100 (the default) will make it prefer to reclaim memory, but can cause performance impact because of the constant need to re-lookup.

This is sort of a continuation of an old discussion.

B.P., Before Puppy, I was runninng the Mint equivalent of live mode and crashing it by ram overuse.

Excluding auto-managed buffers and cache, I want to know how much the system uses at boot, both tmpfs and process, and how much is used by discretionary user activity.

As I type LxTask reports I am using 135 MB of 2gb. That is process memory and obviously not a comprehensive account of that 2gb.

If you have a container of water, vapor may be nebulous, but what is irrefutably liquid should be plainly measurable.

I wouldn't use a 2mb .sfs that uses 10mb of ram loading, and that usage shouldn't be so esoteric developers aren't even aware of it.


Re: .sfs ram usage

Posted: Thu Dec 30, 2021 7:41 am
by JASpup
JASpup wrote: Thu Dec 30, 2021 3:12 am

B.P., Before Puppy, I was runninng the Mint equivalent of live mode and crashing it by ram overuse.

I make typos all the time, and runninng doesn't look like one of them.


Re: .sfs ram usage

Posted: Fri Dec 31, 2021 12:44 am
by mikewalsh

@JASpup :-

I'm not the best person to judge what you're trying to achieve. With 5TB+ of storage, 32GB of RAM, and around 60 GB of swap space spread across the system, I'm probably inhabiting a totally different planet as far as you're concerned.

I do, however, remember what it's like running Pups on a low-spec P4 system with 1.5 GB of RAM, and just 64 GB of storage. Even then, I never concerned myself as to the exact amount of RAM the actual SFS 'loading' mechanism used.

Y'know, this could be interpreted as being borderline obsessive here..... :? :shock: :lol:

(*Just an observation, like...*)

Mike. ;)