linux-kernel - RE: Regression with SLUB on Netperf and Volanomark

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]

Date:	Fri, 4 May 2007 11:27:54 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Tim Chen <tim.c.chen@...ux.intel.com>
cc:	"Chen, Tim C" <tim.c.chen@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"Zhang, Yanmin" <yanmin.zhang@...el.com>,
	"Wang, Peter Xihong" <peter.xihong.wang@...el.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: RE: Regression with SLUB on Netperf and Volanomark

If I optimize now for the case that we do not share the cpu cache between 
different cpus then performance way drop for the case in which we share 
the cache (hyperthreading).

If we do not share the cache then processors essentially needs to have 
their own lists of partial caches in which they keep cache hot objects. 
(something mini NUMA like). Any writes to shared objects will cause
cacheline eviction on the other which is not good.

If they do share the cpu cache then they need to have a shared list of 
partial slabs.

Not sure where to go here. Increasing the per cpu slab size may hold off 
the issue up to a certain cpu cache size. For that we would need to 
identify which slabs create the performance issue.

One easy way to check that this is indeed the case: Enable fake NUMA. You 
will then have separate queues for each processor since they are on 
different "nodes". Create two fake nodes. Run one thread in each node and 
see if this fixes it.
-
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/