linux-kernel - Re: SLUB performance regression vs SLAB

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] [day] [month] [year] [list]

Message-Id: <20071005.143124.74549703.davem@davemloft.net>
Date:	Fri, 05 Oct 2007 14:31:24 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	a.p.zijlstra@...llo.nl
Cc:	cebbert@...hat.com, willy@...ux.intel.com, clameter@....com,
	nickpiggin@...oo.com.au, hch@....de, mel@...net.ie,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	dgc@....com, jens.axboe@...cle.com, suresh.b.siddha@...el.com
Subject: Re: SLUB performance regression vs SLAB

From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Date: Fri, 05 Oct 2007 22:32:00 +0200

> Focus on the slab allocator usage, instrument it, record a trace,
> generate a statistical model that matches, and write a small
> programm/kernel module that has the same allocation pattern. Then verify
> this statistical workload still shows the same performance difference.
> 
> Easy: no
> Doable: yes

The other important bit is likely to generate a lot of DMA traffic
such that the L2 cache bandwidth is getting used on the bus
side by the PCI controller doing invalidations of both dirty
and clean L2 cache lines as devices DMA to/from them.

This will also be exercising the memory controller, further contending
with the cpu when SLAB touches cold data structures.
-
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/