Category Archives: Uncategorized

Optimizing Memory Consumption on Small Systems

Posted on by

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:

crashkernel=0

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

swiotlb=0

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.

Slack Notifications Hang KDE – The Workaround

Posted on by

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.

Virtualized Windows 10 – i440FX vs Q35

Posted on by

QEMU supports two x86 chipsets it can emulate. The very ancient (1996) i440FX chipset and the more recent (2007) Q35 chipset. For a long time, Q35 was advised against for GPU passthrough because some parts weren’t quite fully addressed. On the other hand, the advantage of Q35 is that it supports PCIe natively. i440FX only supports PCI and all passed through hardware had to pretend to be PCI rather than PCIe. In theory, this means that Q35 should lead to a slightly lower emulation overhead, so I decided to test it between different workstation seats on my virtualized workstation server.

Initial results are quite interesting. I left both VMs idle after booting with as close to identical setup as there can be (other than Q35 vs i440FX). After around 3 hours, I measured the total CPU time spent while idling. These are two otherwise identical VMs sitting at their login screens after booting:

15:24.01 i440fx
11:53.29 q35

So it looks like the VM based on Q35 emulated chipset used about 23% less CPU while idling. I haven’t noticed any performance difference by the seat of my pants after conversion to Q35. I haven’t actually run any other benchmarks yet, but a 23% CPU saving with Q35 when idling seems significant. Especially if you have a lot of Windows VMs running that are sitting idle most of the time.