oom_ext. Oh boy.

Really not hugely comfortable with this...

https://lore.kernel.org/lkml/20250428033617.3797686-1-roman.gushchin@linux.dev/

@ljs vmamerge_ext is closer and closer. Don't say I didn't warn you.

@hyeyoo Great idea! So that we can reimplement SLOB in it.

@ljs @vbabka

@hyeyoo Also, how about using S3 buckets for SLAB objects, hmm?? The accounting infrastructure is mostly in place already.

@ljs @vbabka

@hyeyoo Stop me: with oom_ext in place, in theory, I can trigger an s3fs-fuse mountpoint, create a swapfile on it, and then activate it.

@ljs @vbabka

@oleksandr @hyeyoo @vbabka yeah @brauner can we get rid of fuse and replace it with fs_ext please for efficiency? Thanks

@ljs This is intended to augment sytemd-oomd (which is the upstreamed version of Meta's oomd)?

@brauner seems like it's intended to replace it? Why would you do pre-emptive oom when you can just have all the logic in the kernel I guess?

But maybe still useful to pre-empt...

I'm quite concerned about having bpf make decisions in such a critical place.

A great advantage of oomk is it's really simple and straightforward to understand, and oomd and friends can be used otherwise.

@ljs @brauner It can always get worse. Like: In case of memory allocation failure, make an API call to chatgpt and ask which process should be killed (giving it zero context). Then parse the output for the first valid PID…
EDIT: This solution would be marketed as Intelligent Memory Management™.

@ptesarik @ljs @brauner good news is that DNS won't work... so the call will fail

@ljs @brauner @hny Good idea: Put blame on infrastructure engineers. It's their f*ing job to make sure DNS works, ain't it?

@ljs @oleksandr @hyeyoo @vbabka @brauner You mean run not fully trusted code in kernel-space? I offer to renew my efforts on SandBox Mode. That should make it much faster!

@ptesarik Just ask LKML-GPT to vibe-review it.

@ljs @hyeyoo @vbabka @brauner

@ptesarik @ljs @brauner we're site unreliability engineers, sir

doing our best.