[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Whonix-Workstation 14 - increase default RAM?

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.

1 Like

What did you use to check free RAM?

Whonix-Gateway… Konsole…

Compositor enabled.

  • Used: more RAM
  • Free: less RAM
              total        used        free      shared  buff/cache   available
Mem:            744         397          73          12         273         222
Swap:           509           0         509

Compositor disabled.

  • used: less RAM
  • free: less RAM
              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 https://github.com/Whonix/swap-file-creator to zram.

1 Like

This seems newer and better maintained.


https://www.archlinux.org/packages/community/any/systemd-swap/

1 Like

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.

1 Like

Btw that is implemented anyhow. Key isn’t saved anywhere. So lost on shutdown. And shred is an opt-in, no default.

1 Like


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.

1 Like

A nice zram vs zswap use case explanation in plain English


Longer story here:

1 Like

Figured it out. Needed to enable zram in config.

https://github.com/Nefelim4ag/systemd-swap/issues/51#issuecomment-368136102

1 Like

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?


https://github.com/Nefelim4ag/systemd-swap is pretty easy to install and use if someone else likes to try.

1 Like

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.

https://packages.debian.org/stretch/e17

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.

1 Like

@HulaHoop

  • Did the package upgrades fix KVM shared folder?
  • I don’t want to make more changes to Whonix 14. Even no new packages. I want to get it out ASP and not being distracted by new packages and any issues that they may cause. Like syncthing ships a systemd unit file. They’ll (like wormhole) would need an uwt wrapper. Just small stuff but can easily require always another build.

New build being uploaded now.

1 Like

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.

https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Facebook-OOMD

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]