Memory Folios Updated A 14th Time For Improving Linux Memory Management

[phoronix]

Phoronix: Memory Folios Updated A 14th Time For Improving Linux Memory Management

Matthew Wilcox of Oracle has sent out his 14th revision to the memory "folios" patch-set for this new struct that aims to improve Linux's memory management code and ultimately better performance...

https://www.phoronix.com/scan.php?page=news_item&px=Memory-Folios-14

[ddriver]

Pf, 4k pages are so previous century. Sheer peasantry, peasantry I say.

[CochainComplex]

I'm really looking forward to this patchset getting mainlined. Michael any chance for benchmarks yet to get a glimps of potential performance uplifts (or regressions in particular cases)?

Edit: Michael is already firing up benchmarks - I have somehow missed that sentence - thx@ermo for pointing it out

[ermo]

I'm really looking forward to this patchset getting mainlined. Michael any chance for benchmarks yet to get a glimps of potential performance uplifts (or regressions in particular cases)?

In case you missed it:

(...)
Given the possible performance wins, I'll also be firing up some kernel benchmarks with memory folios shortly.

[CochainComplex]

Oh damn THX yes i have obviously missed it

[Michael]

I'm really looking forward to this patchset getting mainlined. Michael any chance for benchmarks yet to get a glimps of potential performance uplifts (or regressions in particular cases)?

Edit: Michael is already firing up benchmarks - I have somehow missed that sentence - thx@ermo for pointing it out

Yes have benchmarks running on the Folio-enabled kernel at this very moment.

[CochainComplex]

Yes have benchmarks running on the Folio-enabled kernel at this very moment.

Can't wait for the results

[coder]

The real head-scratcher is why this wasn't fixed sooner.

It's usually painfully obvious when an API gets the abstraction level wrong. Sounds like that was the case here, too.

[arQon]

The real head-scratcher is why this wasn't fixed sooner.

I can't speak for all the (apparently pretty poor) "defensive" code in there, but you you only need a handful of places that assume pages are 4K (or any other specific size) to run into all kinds of weird/broken/whatever behavior, all of which will always be blamed on the patchset rather than the defective code. Tracking that sort of thing down is a lot more work than writing a new allocator is.

The kernel "shouldn't" have much of that, but half the gnu utils still think a disk sector is 512 bytes, so...

[gilboa]

I can't speak for all the (apparently pretty poor) "defensive" code in there, but you you only need a handful of places that assume pages are 4K (or any other specific size) to run into all kinds of weird/broken/whatever behavior, all of which will always be blamed on the patchset rather than the defective code. Tracking that sort of thing down is a lot more work than writing a new allocator is.

The kernel "shouldn't" have much of that, but half the gnu utils still think a disk sector is 512 bytes, so...

Hopefully anyone using pages also uses PAGE_SIZE / PAGE_ORDER for memory size calculations, so cleaning up the code and moving it to folios API will be easy.
That said, just checked my own (proprietary) tree, and a lot of stuff hangs on having 4096 byte pages.

Oh, well, guess I'll call it job security