Check out the lru_gen_min_ttl from MGLRU.

> But if you do that, things like the USPS donkey train [0] would be stripped, the US military would / should be reduced to a fraction of its current size or down to nothing, etc.

and that is a problem because? These are funded by tax dollars collected. It's impossible for people to stop paying for them whether they make sense or not.

in a sense, RCU is garbage collection.

I wonder how well the caching works. The FAQ says 30 days, so you might be getting a pretty stale result. That combined with Google's "fun fact: 15% of all Google searches have never been searched before", makes me wonder how identifying these queries can be.

The rust language is not well-specified, and if you take rust as the language specified by the compiler, then it has many soundness bugs. So even if you stay within "safe rust", you can segfault.

The "memory safety" of rust is oversold since "safety" is not formally proven for the rust language. While anecdotally memory-related bugs seem less likely, rust without unsafe is not absolutely safe.

iirc the formal correctness of Rusts memory model was proven by Ralf Jung https://research.ralfj.de/thesis.html

There's a good balance between preventing accidents and reducing friction.

One person having "god-mode" access isn't usually that terrible.

Funny enough, Google is still on cgroup v1. Writeback is also very aggressive such that most of pagecache is clean.

The author has identified the issue to be memcg reparenting causing a spike in CPU usage. Reparenting mostly solves a problem with zombie memcg, where the memcg lingers because some resource is still charged to it. In the extreme case you can end up with tens if thousands of zombies. The zombie memcg problem is not unique to cgroup v2, but reparenting is fairly recent.

The article solves the cpu spike by disabling the io or memory controller, but if one would like to use those controllers, a better way to charge memory would be nice.

It is unfortunate that it's clear where the memory should be charged, but the kernel does not provide reliable way to deterministically charge that memory. If anyone has any design ideas, please feel free to chime in!

looking at the linked launchpad bug it seems the issue is lock contention.

simply pacing the reparenting would solve the problem, and reworking the locking (to allow the reparenting process to work in batch maybe?) would make sure it finishes relatively quickly.

Linux excels at drivers and device support. The actual kernel is nowhere near as good as its competitors.

nix-ld[1] and envfs[2] provide a decent workaround for unpatched binaries, in case you haven't heard of these tools yet.

[1] https://github.com/nix-community/nix-ld [2] https://github.com/Mic92/envfs

The blog post linked by [1] is quite good.

I use NixOS for the base system and Flatpak+Containers for everything else. I would rather keep it this way as it keeps everything nice and separated, and less chance of things breaking from Nix being rolling.