[nicklaf]

I have an older Chromebook (c720), which is really quite memory starved (2GB RAM), and have experienced ChromeOS completely frying the SSD simply through prolonged tab-heavy swapping.

Now, I've replaced the SSD and installed a non-Google Linux distro, and would like to limit the amount of swapping Firefox can do.

I had been planning to simply use cgroups' memory features to limit the amount of memory consumed by Firefox processes, but if I am to understand the article (which I admit I didn't read in full detail), I should also be able to tune swapping to limit the actual amount of swapping that takes place, avoiding a drastic uptick in SSD wear whenever open too many tabs.

That, and perhaps a Firefox extension that suspends background tabs in memory (which I've used before with a certain amount of effectiveness in the pre-WebExtension days).

[reynhout]

ChromeOS does not use an on-disk swap partition. Your SSD died just because cheap SSDs like those typically found in Chromebooks die early. :(

ChromeOS uses zram instead of physical swap, which works quite well, even on 2GB models. Zram is available in any Linux distro, being built into the kernel, and is also the default configuration in GalliumOS (Ubuntu+Xfce for Chromebooks, most of which are less broadly compatible than your PEPPY).

[tombrossman]

Firefox has a couple options which may help you get by. I can't guarantee these will fix everything but they are worth experimenting with.

about:memory has various options, including a 'minimize memory usage' button and profiling tools.

about:preferences has Privacy & Security > Cached Web Content > Override automatic cache management (select and set at 500MB, 1GB, or whatever works best).

[javitury]

Yep, you can adjust the max amount of cache it will store in ram and disk(separately).

[vanderZwan]

I don't see any option to separate that in the settings page, is it hidden behind a flag somewhere?

[javitury]

In about:config search for browser.cache.memory.capacity and browser.cache.disk.capacity.They are in kilobytes. To enable or disable any of those caches use browser.cache.disk.enable and browser.cache.memory.enable.

[vanderZwan]

Thanks!

[nicklaf]

Thank you, I had not known about about:memory. Interesting.

[bruce_one]

Setting the `swappiness` value might be of use to you.

Setting a lower value (min is 0, default is 60 iirc, max is 100, so above half) reduces the likelihood of the kernel swapping. The lower the number the fuller ram needs to be before the kernel will start swapping. Hence a low number will mean that less swapping will happen, hence meaning less SSD wear.

[nicklaf]

Thanks, I should simply start with that.

Along with a hard limit set by cgroups so that browser tabs start being killed in order to stop the swap from being overwhelmed when memory is being used well beyond its capacity.

(I'd be interested to know if 'swappiness' already effectively implements the following system-wide, but here goes.)

Now that I think of it, it's not so much the quantity of disk storage being consumed by swap, so much as the number of write / delete transactions. One thus wonders if an approach in which the browser somehow favors a small number of tabs to keep in ram, and then dumps the state of the remaining tabs to disk, might be just as effective, but without worrying about the growth of swap. Then, when the user opens a tab that had been saved to disk, if we crudely assume that the memory consumed by open tabs are roughly comparable in memory use, then we can take care of the whole affair of 'swapping' in a single exchange between memory and disk, where we dump the state of the in-memory tab in order to make way for restoring the saved one.

(Or did I just reinvent what swappiness does already? From your description of swappiness, I'm inclined to guess the answer is no. This approach strikes me more akin to using the swapfile as a filesystem, and keeping just a small number of tabs paged into RAM.)