SLUB: [RFC] Per cpu partial lists V3
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest7 patches 5 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | slub: free slabs without holding locks (V2)mm/ | +13 | 0 replies | |
| 2/7 | slub: Remove useless statements in __slab_allocmm/ | +0 | 0 replies | |
| 3/7 | slub: Prepare inuse field in new_slab()mm/ | +2 | 0 replies | |
| 4/7 | slub: pass kmem_cache_cpu pointer to get_partial()mm/ | +15 | 0 replies | |
| 5/7 | slub: return object pointer from get_partial() / new_slab().mm/ | +73 | 0 replies | |
| 6/7 | slub: per cpu cache for partial pagesinclude/ mm/ | +294 | 1 reply | |
| 7/7 | slub: update slabinfo tools to report per cpu partial list statisticstools/ | +8 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [slub p3 0/7] SLUB: [RFC] Per cpu partial lists V3
V2->V3 : Work on the todo list. Still some work to be done to reduce
code impact and make this all cleaner. (Pekka: patch 1-3 are cleanup patches of general usefulness. You got #1 already 2+3 could be picked up w/o any issue).
The following patchset introduces per cpu partial lists which allow a performance increase of around ~15% if there is contention for the nodelock (can be tested using hackbench).
These lists help to avoid per node lock overhead. Allocator latency could be further reduced by making these operations work without disabling interrupts (like the fastpath and the free slowpath) as well as implementing better ways of handling ther cpu array with partial pages.
I am still not satisfied with the cleanliness of the code after these changes. Some review with suggestions as to how to restructure the code given these changes in operations would be appreciated.
It is interesting to note that BSD has gone to a scheme with partial pages only per cpu (source: Adrian). Transfer of cpu ownerships is done using IPIs. Probably too much overhead for our taste. The use of a few per cpu partial pages looks to be beneficial though.
Note that there is no performance gain when there is no contention.
Performance:
Before After
./hackbench 100 process 200000
Time: 2299.072 1742.454 ./hackbench 100 process 20000 Time: 224.654 182.393 ./hackbench 100 process 20000 Time: 227.126 182.780 ./hackbench 100 process 20000 Time: 219.608 182.899 ./hackbench 10 process 20000 Time: 21.769 18.756 ./hackbench 10 process 20000 Time: 21.657 18.938 ./hackbench 10 process 20000 Time: 23.193 19.537 ./hackbench 1 process 20000 Time: 2.337 2.263 ./hackbench 1 process 20000 Time: 2.223 2.271 ./hackbench 1 process 20000 Time: 2.269 2.301