Optimizing Memory Consumption on Small Systems

Optimizing Memory Consumption on Small Systems – Again

Many moons ago, I wrote about optimizing memory availability on a small system with only 512MB of RAM. Systems got bigger since then, but there are many cases where such optimisations are still needed, and default configurations are not always cooperative with that goal out of the box. When working all day every day in the MySQL consulting business, this kind of thing matters to cost conscious clients with a lot of VMs.

So here are a few additional setting to consider for systems with no more than 4GB of RAM:


If your links distro configures a crashkernel reservation by default, this will save some memory.


Only use this if you have less than or equal to 4GB of memory. But if you do, it will save approximately 256MB of RAM.

Between these and some of the settings in the previous article mentioned, on something like the Oracle Cloud free-forever tier instance with only 1GB of RAM, it can make the difference between unusable and useful.

Linux with UP2715K (or T221 or any other composite monitor), Xorg, Xinerama, XRandR

It is most unfortunate that the best monitors of any era are always a little quirky. I used an IBM T221 for over a decade as my main work and play monitor with it’s, for the time (they came out in 2003!), staggering 3840×2400 (4K+) resolution. But the fact that it had to pretend to be two separate monitors to shift enough pixels to achieve such high resolutions at a decent refresh rate always caused problems, especially on Linux.

The much younger Dell UP2715K also requires two separate DisplayPort inputs to achieve the full 5K (5120×2880) resolution.

The problem is that this kind of a setup is very unusual. I am aware of only the two mentioned monitors that use this kind of input arrangement. Consequently, most developers of desktop environments and GPU drivers seemingly couldn’t care less about supporting it. I covered how to deal with this with a T221 monitor in the past using both Nvidia drivers (which have built in option to lie to the desktop environment about the monitor geometry) and AMD drivers (which require use of the fakexinerama LD_PRELOAD library).

The problem is that both of these workarounds require Xinerama support, and this is mostly being deprecated and removed. Modern Xorg, for example, by default has Xinerama disabled and XRandR (as a more modern replacement) enabled. Unfortunately, Nvidia drivers don’t seem to have the option to fake the RandR geometry data.

So, to make this work, we need to pass Xorg options that are not passable purely via xorg.conf. The trick we used years ago with T221 on Linux no longer work. How do we do this? Modern EL7/EL8/EL9 ship with a shell script for /usr/bin/Xorg:

# Execute Xorg.wrap if it exists otherwise execute Xorg directly.
# This allows distros to put the suid wrapper in a separate package.

if [ -x "$basedir"/Xorg.wrap ]; then
	exec "$basedir"/Xorg.wrap "$@"
	exec "$basedir"/Xorg "$@"

We can modify this to additionally pass additional parameters: -extension RANDR +xinerama

But it turns out that as of EL9, this breaks gdm login. So we have to run gdm without these extra Xorg options, but for the real user session we have to add those options in so that both gdm and KDE plasma work. Thankfully, there is an easy way to detect whether Xorg is running for gdm login or a real user because gdm login runs as the gdm user, but a user session runs as that user. So to make it all work, we modify the Xorg shell script wrapper as follows:

# Execute Xorg.wrap if it exists otherwise execute Xorg directly.
# This allows distros to put the suid wrapper in a separate package.



if [ "$USER" != "gdm" ]; then
	EXTRA="-extension RANDR +xinerama"

if [ -x "$basedir"/Xorg.wrap ]; then
	exec "$basedir"/Xorg.wrap $EXTRA "$@"
	exec "$basedir"/Xorg $EXTRA "$@"

Combine that with a xorg.conf fragment similar to what we used before with the T221, and we have a fully working GDM login with KDE plasma desktop. All the benefits of fantastic image quality, and none of the compromises.

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1080Ti"
    Option         "NoLogo" "1"
    Option         "TripleBuffer" "True"

Section "Screen"
	Identifier     "Screen0"
	Device         "Device0"
	Monitor        "Monitor0"
	DefaultDepth    24
	Option	"Coolbits" "28"
	Option	"UseEdidDpi" "False"
	Option	"DPI" "96 x 96"
	Option	"TwinView" "True"
	Option	"ConnectedMonitor" "DP-0, DP-2"
	Option	"NoTwinViewXineramaInfo" "True"
	Option	"nvidiaXineramaInfo" "False"
	Option	"MetaModes" "DP-2:2560x2880 +0+0, DP-0:2560x2880 +2560+0"
	SubSection     "Display"
		Depth	24

Obviously these options require an Nvidia GPU driver. For AMD GPUs you will have to apply a different workaround.

Slack Notifications Hang KDE – The Workaround

This has been annoying me for a while on EL8 (CentOS / Rocky / Alma / RedHat). It actually affects more than just Slack – it can affect most things that send desktop notifications, but Slack is where I first noticed it. I haven’t been able to find a proper fix for it, but here is a workaround:

sudo rm /usr/share/dbus-1/services/org.kde.plasma.Notifications.service

Notifications that used to hang the app for minutes will now not go off at all and everything will continue smoothly.