linux-kernel - 2.6.24-rc2 slab vs slob tbench numbers

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

Message-Id: <200711092336.56172.nickpiggin@yahoo.com.au>
Date:	Fri, 9 Nov 2007 23:36:56 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Christoph Lameter <clameter@....com>, linux-kernel@...r.kernel.org
Subject: 2.6.24-rc2 slab vs slob tbench numbers

Hi,

Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
core x86 system, with 1 NUMA node per socket. With kernel 2.6.24-rc2,
comparing slab vs slub allocators.

I run from 1 to 16 client threads, 5 times each, and restarting
the tbench server between every run. I'm just taking the highest
of each of the 5 tests (because the scheduler placement can
sometimes be poor). It's not completely scientific, but from the
graph you can guess it is relatively stable and seems significant.

Summary: slub is consistently slower. When all CPUs are saturated,
it is around 20% slower. Attached is a graph (x is nrclients, y
is throughput MB/s)

If I can help with reproducing it or testing anything, let me know.
I'll be trying out a few other benchmarks too... anything you want
me to test specifically and I can try.

Thanks,
Nick

Download attachment "slab.png" of type "image/png" (4614 bytes)