Re: [PATCH 1/3] slub: set a criteria for slub node partial adding

[David Rientjes]

On Wed, 7 Dec 2011, Shaohua Li wrote:

> interesting. I did similar experiment before (try to sort the page
> according to free number), but it appears quite hard. The free number of
> a page is dynamic, eg more slabs can be freed when the page is in
> partial list. And in netperf test, the partial list could be very very
> long. Can you post your patch, I definitely what to look at it.

It was over a couple of years ago and the slub code has changed 
significantly since then, but you can see the general concept of the "slab 
thrashing" problem with netperf and my solution back then:

	http://marc.info/?l=linux-kernel&m=123839191416478
	http://marc.info/?l=linux-kernel&m=123839203016592
	http://marc.info/?l=linux-kernel&m=123839202916583

I also had a separate patchset that, instead of this approach, would just 
iterate through the partial list in get_partial_node() looking for 
anything where the number of free objects met a certain threshold, which 
still defaulted to 25% and instantly picked it.  The overhead was taking 
slab_lock() for each page, but that was nullified by the performance 
speedup of using the alloc fastpath a majority of the time for both 
kmalloc-256 and kmalloc-2k when in the past it had only been able to serve 
one or two allocs.  If no partial slab met the threshold, the slab_lock() 
is held of the partial slab with the most free objects and returned 
instead.

> What I have about the partial list is it wastes a lot of memory.

That's not going to be helped with the above approach since we typically 
try to fill a partial slab with many free objects, but it also won't be 
severely impacted because if the threshold is kept small enough, then we 
simply return the first partial slab that meets the criteria.  That allows 
the partial slabs at the end of the list to hopefully become mostly free.

And, for completeness, there's also a possibility that you have some 
completely free slabs on the partial list that coule be freed back to the 
buddy allocator by decreasing min_partial by way of 
/sys/kernel/slab/cache/min_partial at the risk of performance and then 
invoke /sys/kernel/slab/cache/shrink to free the unused slabs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/