Messages in this thread | | | Date | Wed, 24 Aug 2016 09:20:57 +0100 | From | Mel Gorman <> | Subject | Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats |
| |
On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote: > Do we have any documentation/study about which particular workloads > benefit from which allocator? It seems that most users will use whatever > the default or what their distribution uses. E.g. SLES kernel use SLAB > because this is what we used to have for ages and there was no strong > reason to change that default.
Yes, with the downside that a reliance on high-orders contended on the zone lock which would not scale and could degrade over time. If there were multiple compelling reasons then it would have been an easier switch.
I did prototype high-order pcp caching up to PAGE_ALLOC_COSTLY_ORDER but it pushed the size of per_cpu_pages over a cache line which could be problematic in itself. I never finished off the work as fixing the allocator for SLUB was not a priority. The prototype no longer applies as it conflicts with the removal of the fair zone allocation policy.
If/when I get back to the page allocator, the priority would be a bulk API for faster allocs of batches of order-0 pages instead of allocating a large page and splitting.
-- Mel Gorman SUSE Labs
| |