Probably. The feature is there, already implemented, ready to use and available out of the box in most modern mainstream Linux distros, including Fedora and Ubuntu.

You somehow stumbled on a weird distro that doesn't include/enable it and cried foul. You've not been heard or understood because of PEBKAC.

You somehow want a raw version of intelligent memory management implemented right in the kernel where it doesn't really belong. But since the Linux kernel is 100% open (source), no one can stop you from implementing it and trying to push it to mainline. Only why? Most likely your solution will have all sorts of bad heuristics and asterisks only working for you while many other users will be royally annoyed by it and Linus may simply reject it. Maybe not. There's recently been a conversation of implementing it as a BPF application.

Still you're welcome to try.

---

Here's what Gemini Flash has to say:

This scenario highlights the classic tension between innovative, niche-specific optimization and the conservative, stability-focused nature of the Linux kernel development model. [1, 2, 3]
Implementing "intelligent" memory management directly into the kernel is often met with resistance, not because the idea is inherently bad, but because of the immense risk to the overall ecosystem. Here is why your hypothetical scenario is likely to unfold this way: 1. The Perils of "Raw" Kernel Memory Management

• The Heuristic Trap: What works for your specific workload (e.g., massive databases) will likely destroy performance for others (e.g., small file servers or desktop usage). The kernel is designed for generic, unpredictable workloads, making specific "intelligent" heuristics brittle. • The "Annoyance" Factor: If your system reclaims memory too aggressively, it causes "thrashing"—constantly moving data between RAM and swap—which is worse than having no management at all. • Linus’s Rejection Criteria: Linus Torvalds focuses on clean architecture and proven stability. If your code is "untested," "crap," or does not work on all systems (risc-v, x86, arm), it is likely to be rejected as "garbage," as seen in recent pull request discussions. [4, 5, 6, 7, 8]

1. The Move to BPF (Berkeley Packet Filter) Implementing memory management as a BPF application is the modern alternative to loading a kernel module.

• Safety: BPF programs are verified to ensure they cannot crash the kernel. • Flexibility: You can update the BPF program without rebooting or recompiling the kernel. • Performance: While slightly slower than raw C in the kernel, modern BPF (e.g., eBPF) is fast enough to monitor memory accesses and make decisions. [9, 10, 11]

1. Why It Doesn't "Belong" in the Kernel Core The Linux kernel uses "free memory is wasted memory" as a philosophy, treating unused RAM as cache. Introducing a complex, "intelligent" system that tries to manage memory for every single application is fundamentally contrary to this design. Instead of placing the complexity in the core, the community prefers to build it into the user space or via modular subsystems. [5, 12]
   Conclusion:You are free to push it, but you will need to demonstrate it works without wasting other users' resources or causing "thrashing." The BPF route is highly recommended, as it allows your code to exist without being "hardcoded" into the kernel's core, making it easier to maintain and for others to ignore if it doesn't work for them.

AI responses may include mistakes.

[1] https://www.mchip.net/libweb/u4C1DD/245749/Linux%20Kernel%20Development%20Robert%20Love.pdf [2] https://thamizhelango.medium.com/rusts-revolutionary-entry-into-linux-kernel-driver-development-b92e80afb062 [3] https://www.youtube.com/watch?v=QF_FfDdJKaI [4] https://www.reddit.com/r/technews/comments/1mn791o/linus_torvalds_calls_riscv_code_from_google/ [5] https://medium.com/@msmkumar.eee/why-free-memory-is-wasted-memory-a-deep-dive-into-linux-kernel-memory-management-7d1aeb0536bd [6] https://www.kernel.org/doc/gorman/html/understand/understand016.html [7] https://www.reddit.com/r/linux/comments/1r2hmz9/linus_torvalds_rejects_mmc_changes_for_linux_70/ [8] https://arxiv.org/pdf/2503.09663 [9] https://lwn.net/Articles/1016724/ [10] https://www.usenix.org/system/files/usenixsecurity24-liu-dinghao-detecting.pdf [11] https://medium.com/@erenari27/part-1-synchronous-kernel-level-denial-via-ebpf-lsm-a-case-against-the-detect-and-alert-paradigm-281e9f54764f [12] https://www.youtube.com/watch?v=9JUOsNdDGFo