Note that over provisioning ram works best when combined with compressed swap via zram in Linux. It prevents tremendous slowdowns or system crashes by converting the ram dynamically to a compressed swap space in ram. It has a performance penalty, but only kicks in when your tasks exceed physical memory. It used to be the only way to reliable way to get 4 Rosetta tasks running on a 4gb pi.Overprovisioning sounds tempting. I learned from @Endgame124 that this is even possible in a single client instance, by configuring >100% allowed RAM usage via an edited global_prefs_override.xml. *However*, based on what I saw at other projects which use vboxwrapper (I haven't tested this new Rosetta application yet), you definitely want to maintain a very responsive system at all times. Otherwise you might frequently see tasks which get stuck with "Postponed: VM job unmanageable, restarting later". Such tasks can then only be aborted, IME, with the respective loss of the task's computation up until that point. (Edit: There may be workarounds to get such tasks back up and running, but they don't seem reliable and feasible to automate.) Therefore I have doubts that overprovisioning of RAM is the way to go with a vboxwrapper based application like this.