Linux 6.10 SLUB Optimization To Reduce Memory Consumption In Extreme Scenarios

[phoronix]

Phoronix: Linux 6.10 SLUB Optimization To Reduce Memory Consumption In Extreme Scenarios

A patch to the Linux kernel's SLUB allocator has been queued ahead of the upcoming Linux 6.10 merge window to help reduce memory consumption in extreme scenarios...

https://www.phoronix.com/news/Linux-6.10-SLUB-Optimization

[Kjell]

Chen found that the number of allocated objects via /proc/slabinfo dropped from 13,519,712 down to 4,200,768 objects

-31%.. Incredible work!!!

[FuchtelJockel]

-31%.. Incredible work!!!

-69 %

[ehansin]

SLOB was messy, SLAB ended up falling flat - let's hope SLUB doesn't end up... wait for it... "sluggish"!!

[cend]

The remaining SL*B acronyms are SLEB and SLIB. Maybe SLYB to force a sixth vowel since six-vowel phonology exists in real life. (Mandarin Chinese is one, at least if we take Pinyin romanization at face value.) We don't have so much space for full rewrites of a SLAB allocator before we have to get smarter.

Things aside, this looks like a nice incremental change.

[toves]

Nice.
Resource management is one area where blunt theory is impaled on the sharp edges of reality.
Memory management more so than for other resources.
Not a kernel mavin but I think the patch adds some memory (state) of where you got the chunk of memory from so when the same situation next arises you return to the same well as it were.

[GreenReaper]

Slab fragmentation is a big deal for my use case which involves caching a lot of small files (so inodes/dentries aplenty). In prior cases I either used SLAB or set slub_max_order = 2 to avoid it, so I'm glad to see work is being done on this.

[ssokolow]

We don't have so much space for full rewrites of a SLAB allocator before we have to get smarter.

Or dumber. Go the "They're takin' our jerbs!" route. SLERB, SLIRB, ...