Hey there, been playing with the compiler helper, and was wondering:
a) Any recommendations for kernel flags/options to get the best out of a Windows 11 VM running on KVM?
b) LTO - so after some bench-marking (cachyos-benchmarks) , I couldn’t see any improvement with compiling for my native CPU (Skylake), which I suspect is down to the fact that I cannot compile with full LTO because of memory constraints. I’ve “only” 16G, and the SystemD OOM killer will nuke the linker (interestingly, taking Hyprland down with it too). Any advice on how to lower the memory requirements? I’ve used modproned-db and also removed things like SELinux, Infiband/EEC support, GPS and the audit framework, but it still explodes during the linking phase.
c) I did bit of reading, and I got the impression that a build with Propeller requires a couple of extra steps. Does CachyOS Kernel Manager implement these?
Note: I noticed that even when using modprobed-db and specifying he chipset, various AMD driver are still being built by default.
That is expected. There’s really only 1% performance difference between comparing for generic V1 vs generic V3. It gets smaller down to 0.01% between generic V3 and ZEN3 so don’t even bother compiling for native.
Any advice on improving VM performance? I’m not fussed on overall performance (I was just compiling for fun, I like to tinker), but any recommend flags/scheduler choice for running a VM on KVM?
I’ve been through the Arch guide and performance is pretty solid, just not very fast. That said, I’m running both Visual Studio and SQL Server on it, both of which can take up a fair amount of resources. Hm, will switch to VSCode at the very least.
I noticed the lto thing too. Realistically - I just took a deep dive back through the AMA from Pipewire, and he talks about certain ways people were getting optimization that are now just embedded in the kernel.
Two things he mentions - Pipewire is a pull model for less latency. This has implications for real time kernels where in some cases the periods don’t align very well (I think) so to be careful and think about what’s really happening with the audio.
In other words people perceive Pipewire in subtle but catastrophic ways as being a Jack clone. Because of this, they misunderstand that Pipewire does not run on fixed period in the same way Jack and ALSA do. Pipewire is doing 2 jobs, Jack can carve just focusing on one. I think that may play in to why some of these arguments are falling flat.
Beyond that, I need to draw it out for education - I’m at like 7ms - that’s fine for home lol. Amazing really.
Also, if you can, disable your network adapter, and be mindful of other devices and peripherals. Been reading an old guide and things like that are taken for granted now I think. It’s starting to make sense why music programs hang really hard when the audio driver shuts off inadvertently and why I think Pipewire really will be the de facto solution to so many issues I thought impossible to solve.