re-shrink 'struct page' when SLUB is on.
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest9 patches 18 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/9 | mm: slab/slub: use page->list consistently instead of page->lruinclude/ mm/ | +29 | 0 replies | |
| 2/9 | mm: blk-mq: uses page->list incorrectlyblock/ | +3 | 0 replies | |
| 3/9 | mm: page->pfmemalloc only used by slab/skbinclude/ include/ include/ +3 more | +26 | 0 replies | |
| 4/9 | mm: slabs: reset page at freeinclude/ mm/ mm/ +1 more | +14 | 0 replies | |
| 5/9 | mm: rearrange struct pageinclude/ mm/ mm/ +1 more | +84 | 0 replies | |
| 6/9 | mm: slub: rearrange 'struct page' fieldsinclude/ mm/ mm/ | +192 | 0 replies | |
| 7/9 | mm: slub: abstract out double cmpxchg optioninclude/ init/ mm/ | +5 | 0 replies | |
| 8/9 | mm: slub: remove 'struct page' alignment restrictionsarch/ arch/ arch/ +4 more | +26 | 0 replies | |
| 9/9 | mm: slub: cleanups after code churnmm/ | +68 | 0 replies |
Reviews trailers per patch
1 of 9 patches has a Reviewed-by or Acked-by.
| Patch | David Rientjes | Kirill A. Shutemov |
|---|---|---|
| 1/9 | ||
| 2/9 | A-b | A-b |
| 3/9 | ||
| 4/9 | ||
| 5/9 | ||
| 6/9 | ||
| 7/9 | ||
| 8/9 | ||
| 9/9 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/9] re-shrink 'struct page' when SLUB is on.
This is a minor update from the last version. The most notable thing is that I was able to demonstrate that maintaining the cmpxchg16 optimization has _some_ value.
Otherwise, the code changes are just a few minor cleanups.
---
SLUB depends on a 16-byte cmpxchg for an optimization which allows it to not disable interrupts in its fast path. This optimization has some small but measurable benefits:
http://lkml.kernel.org/r/[email protected]
In order to get guaranteed 16-byte alignment (required by the hardware on x86), 'struct page' is padded out from 56 to 64 bytes.
Those 8-bytes matter. We've gone to great lengths to keep 'struct page' small in the past. It's a shame that we bloat it now just for alignment reasons when we have extra space. Plus, bloating such a commonly-touched structure *HAS* cache footprint implications.
These patches attempt _internal_ alignment instead of external alignment for slub.
I also got a bug report from some folks running a large database benchmark. Their old kernel uses slab and their new one uses slub. They were swapping and couldn't figure out why. It turned out to be the 2GB of RAM that the slub padding wastes on their system.
On my box, that 2GB cost about $200 to populate back when we bought it. I want my $200 back.
This set takes me from 16909584K of reserved memory at boot down to 14814472K, so almost *exactly* 2GB of savings! It also helps performance, presumably because it touches 14% fewer struct page cachelines. A 30GB dd to a ramfs file:
dd if=/dev/zero of=bigfile bs=$((1<<30)) count=30
is sped up by about 4.4% in my testing.
I've run this through its paces and have not had stability issues with it. It definitely needs some more testing, but it's definitely ready for a wider audience.
I also wrote up a document describing 'struct page's layout: