My observations: Disabling compositor freed up a couple hundered MB RAM. Desktop feels more responsive. Only downside is timesync icon is now surrounded by a blackbox.
I wonder how we have inconsistent results about RAM use.
My observations: Disabling compositor freed up a couple hundered MB RAM. Desktop feels more responsive. Only downside is timesync icon is now surrounded by a blackbox.
I wonder how we have inconsistent results about RAM use.
What did you use to check free RAM?
Whonix-Gateway⦠Konsoleā¦
Compositor enabled.
total used free shared buff/cache available
Mem: 744 397 73 12 273 222
Swap: 509 0 509
Compositor disabled.
total used free shared buff/cache available
Mem: 744 353 67 12 324 266
Swap: 509 0 509
Strange?
Are your results similar?
Dynamic. They all create zram in relation to provided RAM.
Considering to fork any of them and then migrate GitHub - Kicksecure/swap-file-creator: Adds encrypted swap file to the system - for better protection of locally stored data and to aid environments with low RAM. https://www.kicksecure.com/wiki/swap-file-creator to zram.
This seems newer and better maintained.
https://www.archlinux.org/packages/community/any/systemd-swap/
OK I used free -m for more accuracy:
No compositor. free ram:
365
Compositor. free ram:
350
15 MB savings. Nothing great if you ask me. Its useful in my experience because everything seems snappy. However the taskbar icons become ugly to look at which Iām not sure how to fix.
Offtopic: For swap encrypted files, I suggest you shred the key rather than the entire encrypted swapfile. Its quicker and easier to do.
HulaHoop:
Offtopic: For swap encrypted files, I suggest you shred the key rather than the entire encrypted swapfile. Its quicker and easier to do.
If we use zram I was hoping to ditch swap files anyhow.
Btw that is implemented anyhow. Key isnāt saved anywhere. So lost on shutdown. And shred is an opt-in, no default.
Above two commits work only for new builds. Existing builds have to manually change these settings.
GPL3 Bash Debian packaged
ISC license
BSD 2
GPL3. Debian package. active dev.
A nice zram vs zswap use case explanation in plain English
Longer story here:
Figured it out. Needed to enable zram in config.
does not work on Debian stretch Ā· Issue #51 Ā· Nefelim4ag/systemd-swap Ā· GitHub
Both ZRAM and ZSWAP work bad inside VirtualBox (or virtualizers generally?). Even with 4 CPUs assigned. That might be because CPU inside VM is ineffective? 100 % CPU usage inside the VM once but only ~ 30 % usage on the host. (Viewed using ksysguard.)
My other suggestion is to try zswap which might be more easy going on CPU since older memory pages can be swapped out unlike zram.
I think ZSWAP will always be slower since it uses the disk. Also I donāt think on a gui system is much stuff that should be swapped to disk? Perhaps when heavy multi tasking and some applications are not in use for a long time.
With 768 MB RAM however, only konsole, ksysguard and Tor Browser with ~ 5 tabs lead to ~ 6 seconds delay when switching applications. Not an endurable user experience.
Perhaps ZRAM / ZSWAP arenāt designed for GUI systems? Perhaps our use case (very low RAM plus very low CPU) is just hosed?
GitHub - nefelim4ag/systemd-swap: Script for creating hybrid swap space from zram swaps, swap files and swap partitions. is pretty easy to install and use if someone else likes to try.
At this point the best we can do is run an absolute barebones shell/DE on the GW and reassign any excess freed up RAM to the WS. In the case of Whonix KVM the experience is bearable with 512GW/1024WS. For VBox and Xen you might want to allow full Host CPU passthrough to take advantage of its performance.
A true barebones shell that is fast and looks OK is Enlightenment Desktop developed for 20 years and available in Debian. My reasoning: we donāt need much GUI functionality or integration for our privacy features for the GW. KDE/Qt applications should be able to run alongside it, no problem. It should be more than enough to allow users to administrate their GW if they donāt want to run headless.
As far as tuning CPU performance there are sometricks using nice levels for process execution priority. Ananicy is written by the same guy who did systemd-zram
https://wiki.archlinux.org/index.php/improving_performance#Adjusting_priorities_of_processes
HulaHoop:
At this point the best we can do is run an absolute barebones shell/DE on the GW and reassign any excess freed up RAM to the WS.
Too much work for Whonix 14.
For other releases, letās see.
For VBox and Xen you might want to allow full Host CPU passthrough to take advantage of its performance.
Btw for Qubes (Xen based) there is no issue since Qubes Debian and
Whonix templates (and others) donāt need a desktop environment
installed. Desktop environment runs only in dom0 (in future in GuiVM).
That architecture saves a ton of RAM.
wormhole
) would need an uwt
wrapper. Just small stuff but can easily require always another build.New build being uploaded now.
Iām on it.
Youāre right. Time to move forward and get Whonix 14 out already. You can always make releases more frequently in the future.