Re: [PATCH] mm/slab: Improve performance of gathering slabinfo stats

[Joonsoo Kim <iamjoonsoo.kim@lge.com>]

On Mon, Aug 01, 2016 at 06:43:00PM -0700, Aruna Ramakrishna wrote:
> Hi Joonsoo,
> 
> On 08/01/2016 05:55 PM, Joonsoo Kim wrote:
> >Your patch updates these counters not only when a slabs are created and
> >destroyed but also when object is allocated/freed from the slab. This
> >would hurt runtime performance.
> >
> 
> The counters are not updated for each object allocation/free - only
> if that allocation/free results in that slab moving from one list
> (free/partial/full) to another.
> 
> >>> slab lists for gathering slabinfo stats, resulting in a dramatic
> >>> performance improvement. We tested this after growing the dentry cache to
> >>> 70GB, and the performance improved from 2s to 2ms.
> >Nice improvement. I can think of an altenative.
> >
> >I guess that improvement of your change comes from skipping to iterate
> >n->slabs_full list. We can achieve it just with introducing only num_slabs.
> >num_slabs can be updated when a slabs are created and destroyed.
> >
> 
> Yes, slabs_full is typically the largest list.
> 
> >We can calculate num_slabs_full by following equation.
> >
> >num_slabs_full = num_slabs - num_slabs_partial - num_slabs_free
> >
> >Calculating both num_slabs_partial and num_slabs_free by iterating
> >n->slabs_XXX list would not take too much time.
> 
> Yes, this would work too. We cannot avoid traversal of
> slabs_partial, and slabs_free is usually a small list, so this
> should give us similar performance benefits. But having separate
> counters could also be useful for debugging, like the ones defined
> under CONFIG_DEBUG_SLAB/STATS. Won't that help?

We can calculate these counters by traversing all list so it would not
be helpful except for performance reason. Cost of maintaining these
counters isn't free so it's better not to add more than we need.

Thanks.