linux-kernel - hackbench regression due to commit 9dfc6e68bfe6e

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1269506457.4513.141.camel@alexs-hp.sh.intel.com>
Date:	Thu, 25 Mar 2010 16:40:57 +0800
From:	Alex Shi <alex.shi@...el.com>
To:	linux-kernel@...r.kernel.org
Cc:	cl@...ux-foundation.org, ling.ma@...el.com,
	"Zhang, Yanmin" <yanmin.zhang@...el.com>,
	"Chen, Tim C" <tim.c.chen@...el.com>
Subject: hackbench regression due to commit 9dfc6e68bfe6e

The hackbench benchmark dropped about 3~7% on our 2 sockets NHM machine
on 34-rc1 kernel. We find it is due to commit 9dfc6e68bfe6e, 

commit 9dfc6e68bfe6ee452efb1a4e9ca26a9007f2b864
Author: Christoph Lameter <cl@...ux-foundation.org>
Date:   Fri Dec 18 16:26:20 2009 -0600

    SLUB: Use this_cpu operations in slub

The hackbench is prepared hundreds pair of processes/threads. And each
of pair of processes consists of a receiver and a sender. After all
pairs created and ready with a few memory block (by malloc), hackbench
let the sender do appointed times sending to receiver via socket, then
wait all pairs finished. The total sending running time is the indicator
of this benchmark. The less the better.  
The socket send/receiver generate lots of slub alloc/free. slabinfo
command show the following slub get huge increase from about 81412344 to
141412497, after command "backbench 150 thread 1000" running.

Name                   Objects      Alloc       Free   %Fast Fallb O
:t-0001024                 870  141412497  141412132  94   1     0 3
:t-0000256                1607  141225312  141224177  94   1     0 1 

Via perf tool I collected the L1 data cache miss info of comamnd:
"./hackbench 150 thread 100"

On 33-rc1, about 1303976612 time L1 Dcache missing

On 9dfc6, about 1360574760 times L1 Dcache missing

I also disassemble the mm/built.o file, but seems no special change. 

BRG
Alex 

--
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/