Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1453553

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

From Joonsoo Kim <iamjoonsoo.kim@lge.com>
Newsgroups linux.kernel
Subject Re: [PATCH] mm/slab: Improve performance of gathering slabinfo stats
Date 2016-08-02 04:40 +0200
Message-ID <s1xMC-6FX-5@gated-at.bofh.it> (permalink)
References <s1vB8-5dX-3@gated-at.bofh.it> <s1wdQ-5tW-3@gated-at.bofh.it> <s1xMC-6FX-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] mm/slab: Improve performance of gathering slabinfo stats Aruna Ramakrishna <aruna.ramakrishna@oracle.com> - 2016-08-02 02:20 +0200
  Re: [PATCH] mm/slab: Improve performance of gathering slabinfo stats Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-08-02 03:00 +0200
    Re: [PATCH] mm/slab: Improve performance of gathering slabinfo stats Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-08-02 04:40 +0200
      Re: [PATCH] mm/slab: Improve performance of gathering slabinfo  stats Christoph Lameter <cl@linux.com> - 2016-08-02 17:10 +0200
        Re: [PATCH] mm/slab: Improve performance of gathering slabinfo stats Aruna Ramakrishna <aruna.ramakrishna@oracle.com> - 2016-08-02 19:50 +0200
    Re: [PATCH] mm/slab: Improve performance of gathering slabinfo stats Aruna Ramakrishna <aruna.ramakrishna@oracle.com> - 2016-08-02 04:50 +0200

csiph-web