So Valve has done the work for low VRAM situations with gaming. Could we get dmemcg-booster plasma-foreground-booster-dmemcg in Manjaro repos as well.
I think it would benefit a lot for those who are running into low VRAM situations with gaming on their Manjaro installations.
They seem to be in the aur. Switch to unstable branch and test.
I would rather stay on Stable branch and have those still.
Actually when i look at the source at least of the main package (i am no kde user to have knowledge of their integrations) - it is compiled from rust code on install and does not seem to have some fixed versions of libraries as dependencies, so it should be installable on stable without problems.
If it is a good idea - i do not know. Seems valve changes the default order of priorities if resources become insufficient. But i do not understand cgroups enough to see where they take from (it will obviously deprive the other processes of memory in favor of the game).
Certainly a good idea for a game console, but if it will have side effects on general usage pc - 
I may be getting my projects mixed up but didn’t this rely on a custom built kernel to enable the features as well as these patches?
There are kernel patches required, yes.
This article suggests using a CachyOS kernel as they include the VRAM patches.
Can one simply pamac install linux-cachyos on a Manjaro machine and expect it will work? Would all the hooks and configuration stuff occur in the same way as if a manjaro kernel was installed? I notice the Cachy kernel has extra dependencies.
Such experiment will almost certainly go sideways. There are things in the system depending on stuff in the kernel working a certain way which will not be happy i can imagine.
No. And you should not do so. CachyOS is a highly specialised distribution with different repositories for different architectures.
It would also be a violation of their Repository Usage Policy | CachyOS
That was my thinking as well, but I’m not up with exactly how Cachy and Manjaro build their kernels and/or how compatible/incompatible they might be so had to ask the question.
Fair points!
Reading the Repository Usage Policy its rather contradictory about who can and can’t use it, but that is off topic.
There is always the option of building your own kernel.
I don’t do it often only the occasional experiment, I do admit the time between gets longer - I have come to value the stability of Manjaro’s edge branch.
That said - not so long ago a topic was created on how to build a custom Manjaro kernel.
While I have build a kernel before - I got curios on the concept of making it coexist with the official kernels and decided to learn. The process is documented
If your look at the source of a Manjaro kernel - with new features or patches always use the latest - currently 2026-07-10T22:00:00Z Packages / core / linux72 · GitLab.
Look at the PKGBUILD - compare with CachyOS - or another source documenting the patches you want to apply - then build … it will take more than a few hours to build. There is methods to minimise the build time by only including modules you actually need on your system.
There is a custom script in AUR named modprobed-db which is useful in that regard.
Absolutely, I guess I was curious as to how similar/dissimilar the Arch/Manjaro/Cachy kernels might be.
Back in the day when I was using very new hardware building my own kernel yielded some good results but these days I’m running on a potato and just don’t need those few extra cycles. If I could just drop a prebuilt kernel in and get better performance it might be worth it but I can’t justify the brain cells otherwise.
Interestingly I’ve been reading up on this last week and contemplating how it could be useful in conjunction with modulejail.
Indeed - it goes a level below modulejail as the modules is not even available 
$ systemctl status --user modprobed-db.service
○ modprobed-db.service - modprobed-db scan and store new modules
Loaded: loaded (/usr/lib/systemd/user/modprobed-db.service; enabled; preset: enabled)
Active: inactive (dead) since Sat 2026-07-11 08:43:27 CEST; 13min ago
Duration: 25ms
Invocation: 5dc1181c3aaf4871af59d119a14b65ac
TriggeredBy: ● modprobed-db.timer
Docs: man:modprobed-db(8)
https://wiki.archlinux.org/index.php/Modprobed-db
Main PID: 1679 (code=exited, status=0/SUCCESS)
Mem peak: 11.1M
CPU: 29ms
jul 11 08:43:27 tiger systemd[1663]: Started modprobed-db scan and store new modules.
jul 11 08:43:27 tiger modprobed-db[1679]: No new modules detected
My longterm plan is to investigate the AUR (en) - linux-next-git package to learn how I can modify the default Manjaro PKGBUILD to use it.
$ ls -l ~/.config/modprobed*
-rw-r--r-- 1 fh fh 3269 11 jul 08:43 /home/fh/.config/modprobed.db
-rw-r--r-- 1 fh fh 2907 24 sep 2023 /home/fh/.config/modprobed.db.20230924_081349
-rw-r--r-- 1 fh fh 2597 7 okt 2023 /home/fh/.config/modprobed.db.20231007_085733
-rw-r--r-- 1 fh fh 2657 10 nov 2023 /home/fh/.config/modprobed.db.20231110_133327
-rw-r--r-- 1 fh fh 2706 10 jan 2024 /home/fh/.config/modprobed.db.20240110_093425
-rw-r--r-- 1 fh fh 3929 14 mar 08:30 /home/fh/.config/modprobed.db.20260314_083022
-rw-r--r-- 1 fh fh 3217 14 mar 08:31 /home/fh/.config/modprobed.db.20260314_083144
-rw-r--r-- 1 fh fh 873 5 apr 2023 /home/fh/.config/modprobed-db.conf
But I have never gotten around to it - mainly used when I build linux-next-git
I vaguely recall back when I was building kernels on similar but different hardware, having a script that pretty much did this kind of thing but I can’t remember if it was something I wrote or if it was a common utility. Regardless, that was pre 2000 and much has changed since then.
Memory and CPU cycles were much more expensive back then, particularly at scale on 1500+ machines.
Coming soon https://www.phoronix.com/news/Linux-7.3-Improving-vRAM-Mgmt
The kernel work for improving that video memory management is set to be introduced in the Linux 7.3 kernel. While that’s a celebration on its own, Vock is pursuing more improvements still for bettering the Linux GPU driver video memory management behavior.
With the initial patches having been queued into DRM-Next and slated for merging within the next two weeks for the Linux 7.13 merge window, Natalie Vock published a new blog post today to outline the latest work and results on bettering Linux vRAM management, especially for the AMDGPU driver.
Best wait for 7.3 then
Does it give me more brain cells (preferred) or more performance? 
Long gone memories. I believe everybody on this forum, of a certain age, was rather forced to build kernels at one point or another
Try even building a modern browser (e.g. Waterfox) on a system with only 8GB of RAM and limited storage space, with an external disk partition mounted to give enough space for the build. Not sure I’d even attempt compiling a modern Kernel (especially an Ubuntu one! 
).
Well of course today’s software is rather complex as it has to do many things out of the box. Today’s kernel, with it’s 40 million lines of code, would be rather a pain to build from scratch.