lkml.org 
[lkml]   [2009]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] Check write to slab memory which freed already using mudflap
On Wed, 15 Jul 2009, Nick Piggin wrote:

> > It's my opinion that slab is on its way out when there's no benchmark that
> > shows it is superior by any significant amount. If that happens (and if
> > its successor is slub, slqb, or a yet to be implemented allocator), we can
> > probably start a discussion on what's in and what's out at that time.
>
> How are you running your netperf test? Over localhost or remotely?
> It is a 16 core system? NUMA?
>

I ran it remotely using two machines on the same rack. Both were four
quad-core UMA systems.

> It seems pretty variable when I run it here, although there seems
> to be a pretty clear upper bound on performance, where a lot of the
> results land around (then others go anywhere down to less than half
> that performance).
>

My results from my slub partial slab thrashing patchset comparing slab and
slub were with a variety of different thread counts, each a multiple of
the number of cores. The most notable slub regression always appeared in
the higher thread counts with this script:

#!/bin/bash

TIME=60 # seconds
HOSTNAME=hostname.goes.here # netserver

NR_CPUS=$(grep ^processor /proc/cpuinfo | wc -l)
echo NR_CPUS=$NR_CPUS

run_netperf() {
for i in $(seq 1 $1); do
netperf -H $HOSTNAME -t TCP_RR -l $TIME &
done
}

ITERATIONS=0
while [ $ITERATIONS -lt 10 ]; do
RATE=0
ITERATIONS=$[$ITERATIONS + 1]
THREADS=$[$NR_CPUS * $ITERATIONS]
RESULTS=$(run_netperf $THREADS | grep -v '[a-zA-Z]' | awk '{ print $6 }')

for j in $RESULTS; do
RATE=$[$RATE + ${j/.*}]
done
echo threads=$THREADS rate=$RATE
done

> Anyway, tried to get an idea of performance on my 8 core NUMA system,
> over localhost, and just at 64 threads. Ran the test 60 times for
> each allocator.
>
> Rates for 2.6.31-rc2 (+slqb from Pekka's tree)
> SLAB: 1869710
> SLQB: 1859710
> SLUB: 1769400
>

Great, slqb doesn't regress nearly as much as slub did.

These statistics do show that pulling slab out in favor of slub
prematurely is probably inadvisible, however, when the performance
achieved with slab in this benchmark is far beyond slub's upper bound.

> Now I didn't reboot or restart netperf server during runs, so there
> is possibility of results drifting for some reason (eg. due to
> cache/node placment).
>

SLUB should perform slightly better after the first run on a NUMA system
since its partial lists (for kmalloc-256 and kmalloc-2048) should be
populated with free slabs, which avoid costly page allocations, because of
min_partial.


\
 
 \ /
  Last update: 2009-07-15 22:21    [W:0.050 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site