LWN: Comments on "Proactively reclaiming idle memory"

Proactively reclaiming idle memory

flussence — Fri, 17 May 2019 14:25:06 +0000

The CleanCache/transcendent-memory code is supposed to let userspace code opt in to exactly this way of operation. It'd be perfect for things like X window backing store or decoded media. I've never seen it used in practice on the desktop, sadly.

Proactively reclaiming idle memory

nilsmeyer — Wed, 08 May 2019 13:29:18 +0000

I kinda like the idea, perhaps it's something one can do on a per cgroup basis?

Proactively reclaiming idle memory

epa — Wed, 08 May 2019 10:47:40 +0000

Yes, this is a better way to do the OOM killer: pick a process that has a huge number of allocated pages but a small working set, and forget the pages it hasn't accessed in a long time.

Proactively reclaiming idle memory

Fowl — Wed, 08 May 2019 02:28:58 +0000

This is genius.

Be right back, starting a new VC backed startup called 'OOM-YAGNI" immediately!

Proactively reclaiming idle memory

naptastic — Wed, 08 May 2019 02:16:55 +0000

s/SIGV/SIGKILL/;
# Please forgive errors. I'm typing with a 9-month-old in my lap who really enjoys the taste of my headphone cable.

Proactively reclaiming idle memory

naptastic — Wed, 08 May 2019 02:13:48 +0000

(CW: tangent + entertaining bad idea)

I kinda wish the kernel would always actively move anonymous pages to swap if they get used less often than cache/buffer. Then--bear with me here--if the system still gets full, instead of killing processes directly, the kernel should "forget" just enough LRU pages out of swap to keep things running smoothly. Behavior would be controlled with the same /proc/$pid/oom_* knobs everyone already ignores. ;-) A process owning forgotten pages should keep running, but if it tries to access that page, it gets SIGV. On a long-running system, chances are it's a memory leak, and the process will never even know it's gone.

You can finally get rid of the 03:25 AM cronjob to restart ${leaky application}, and a class of memory pressure concerns goes away.

This is a terrible idea. Do not do this.

Proactively reclaiming idle memory

flussence — Tue, 07 May 2019 16:27:05 +0000

This sounds like the existing swap-prefetch mechanism, but in reverse.

Since that wasn't mentioned I'll have to ask: couldn't they just make the prefetching bidirectional? Idle pages at the tail of the LRU list would get copied to swap but remain live for as long as possible. Ideally the swap space would float near 100% full, so that by the time reclaim under pressure has to happen little to no IO is needed.