By allowing more items per slab, we can improve memory efficiency for
small allocs. If we were just to increase the bitmap size of the
slabzone, we would then waste slabzone memory. So, split slabzone into
two zones, one especially for 8-byte allocs (512 per slab). The
practical effect should be reduced memory usage for counter(9).
Details
- Reviewers
jeff markj - Commits
- rS356717: uma: split slabzone into two sizes
kyua test -k /usr/tests/sys/Kyuafile
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/kern/kern_prot.c | ||
---|---|---|
2057 ↗ | (On Diff #66676) | This and the same in subr_bus.c are actually not necessary with a smallest alloc size of 8 bytes, but I needed to fix them when testing with a smallest alloc size of 4 bytes. |
sys/vm/uma_core.c | ||
---|---|---|
120 ↗ | (On Diff #66676) | Now that virtually nothing uses a hash zone we should only be using offpage slabs for relatively large allocations. Given that I suspect we could dramatically shrink slabzone0 and save a lot of memory until we can embed slabs in pages. 64bit would be more than enough for any case that uses offpage due to fragmentation. |
sys/vm/uma_int.h | ||
428 ↗ | (On Diff #66676) | At this point it feels something like a historical accident to call them hash slabs. |
sys/vm/uma_core.c | ||
---|---|---|
120 ↗ | (On Diff #66676) | Yes... As-is, we could probably tune slabzone0's size down. But with page-embedded slabs, we might then want to tune it back up, or at least to a different value. Perhaps we wait until we get page-embedded slabs in before we tune? |
sys/vm/uma_int.h | ||
428 ↗ | (On Diff #66676) | I agree, it puts the emphasis in the wrong place. I'd like to leave it alone for this commit at least though. |
sys/kern/kern_prot.c | ||
---|---|---|
2057 ↗ | (On Diff #66676) | I'd suggest committing them separately if you weren't already going to. |
sys/kern/kern_prot.c | ||
---|---|---|
2057 ↗ | (On Diff #66676) | Okay, I'll split them out. |
I am happy to tweak parameters and possibly function names in a follow up patch.
Go ahead with this