MGLRU Looks Like One Of The Best Linux Kernel Innovations Of The Year

[elbar]

There is Arm and x86, but on Linux there is systemd but no way to tell if memory is the same as wanted... There is LAN boot, but that's not the same...

[aleksamagicka]

Guys, just please merge this already! Linux behavior in near-OOM situations has been a catastrophe for years. This is not just a handled devices problem, I can run into the OOM catatonia on a laptop with 32 Gigs of RAM.

Wait for the merge window.

[pegasus]

Traditionally, once Linux started to swap large amounts of RAM pages to disk, the desktop would become unbearably slow, to the point that force-rebooting the system was often the quicker solution rather than waiting for the desktop to become responsive again.

Been using linux on desktop since 1996 and the only time this has really been an issue was the MM experiments in early 2.4 kernels, until Linus went mad and yanked the whole thing out in 2.4.10. Otherwise it's been fine, in fact much better than alternatives.

[uid313]

Is this or any of other of Google's commits to Linux kernel things that were first introduced in Google's Zircon kernel used by Fuchsia?

[MadCatX]

Wait for the merge window.

Sure. I just hope it won't get held up again for some bookkeeping minutiae.

[aleksamagicka]

Well I think I saw it while compiling linux-next a few days ago, but I'm not sure...

[sinepgib]

Guys, just please merge this already! Linux behavior in near-OOM situations has been a catastrophe for years. This is not just a handled devices problem, I can run into the OOM catatonia on a laptop with 32 Gigs of RAM.

The "just merge it" attitude is probably one of the reasons we have this catastrophe to begin with. Things should be released when they're ready, not in a hurry. Besides, core memory management, along with filesystems, need specially careful review. You don't want your filesystem corrupted, do you?

[MadCatX]

The "just merge it" attitude is probably one of the reasons we have this catastrophe to begin with. Things should be released when they're ready, not in a hurry. Besides, core memory management, along with filesystems, need specially careful review. You don't want your filesystem corrupted, do you?

The reason for the current lackluster state is that the current MM code simply does not perform well in high memory pressure situations. It was written long time ago when things were different and simpler and it's in a dire need of a bigger update. MGLRU is not some untested junk, it's been in the process of merging for about 6 months and Google has been running it on a huge fleet of their devices for even longer. Whatever remote corner cases may remain in the code, they will have to be found by merging the code and using it in practice.

[sinepgib]

The reason for the current lackluster state is that the current MM code simply does not perform well in high memory pressure situations. It was written long time ago when things were different and simpler and it's in a dire need of a bigger update. MGLRU is not some untested junk, it's been in the process of merging for about 6 months and Google has been running it on a huge fleet of their devices for even longer. Whatever remote corner cases may remain in the code, they will have to be found by merging the code and using it in practice.

High memory pressure situations existed back then. I'd risk saying they were even more common, due to more limited resources at the time. But they needed some MM code for Linux to work, so one can not simply wait in that situation.
Nobody is arguing MGLRU is some untested junk, just that the bar is particularly high for this area. Something that would be merged quickly in other code paths will take much longer and much more review to be accepted in MM, because absolutely everything depends on it, so you need to remove as many edge cases as you can before merging.
Lastly, Google has been running it on a huge fleet of devices with well defined purposes. Mainline requires the code to be good enough for a wider audience. Google doesn't typically run tiny real time systems, for example. It wasn't battle tested in those environments.

[Danny3]

I hope this will be merged as soon as possible!
I've been trying it on Xanmod kernel and it works great for performance and desktop responsiveness.