linux-kernel - Re: Reading /proc/slabinfo causes stalls

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: <0000013a6ad64c95-106bab18-5a15-4c85-bae9-5527aa52f661-000000@email.amazonses.com>
Date:	Tue, 16 Oct 2012 18:29:20 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Pekka Enberg <penberg@...nel.org>
cc:	Avleen Vig <avleen@...il.com>, linux-kernel@...r.kernel.org,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Reading /proc/slabinfo causes stalls

On Tue, 16 Oct 2012, Pekka Enberg wrote:

> > Is this a known condition? Are there work arounds or other ways to get the
> > slab allocation data which don't cause stalls?
>
> What kernel version are you using? What does your .config look like?

slabinfo access requires a mutex which will stall certain slab operations
(shrinking caches, retuning caches, cleaning caches in SLAB).

If the allocator is SLAB then I would think that this is a stall of
slabinfo mutex vs. slab clean operations (gets more frequent the more
processors are in the box).

If this is the case then using the SLUB allocator will fix the issue since
SLUB does not need to perform cache cleaning.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/