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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4a3fe3bc-eb1d-ea18-bd70-98b8b9c6a7d7@oracle.com>
Date:	Mon, 1 Aug 2016 18:43:00 -0700
From:	Aruna Ramakrishna <aruna.ramakrishna@...cle.com>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Mike Kravetz <mike.kravetz@...cle.com>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm/slab: Improve performance of gathering slabinfo stats

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?

Thanks,
Aruna