| 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
| ||
|
Date: Mon, 13 Aug 2007 14:15:12 -0700 (PDT) From: Christoph Lameter <clameter@....com> To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org Subject: Re: [patch 00/23] Atomic operations updates: add cmpxchg_local On Sun, 12 Aug 2007, Mathieu Desnoyers wrote: > I have been asked for a cmpxchg_local implementation by Christoph Lameter so he > can use it to accelerate the slub allocator. Hmmm... I have run my own and tested a variety of approaches on cmpxchg a couple of weeks ago on an Athlong64. There was no significant performance gain (even on a test to just allocate from the same slab cache) and there were actual losses in the free path since the logic got a bit complex. The main performance issue are still the cacheline that are touched and cmpxchg will not change that. The exact code that was used to run these tests can be found in the Performance Counter Patchset that I posted 2 weeks ago. cmpxchg_local SLUB Performance testing ======================== 1. Kmalloc: Repeatedly allocate then free test 10000 times kmalloc(8) = 2.3ms kfree() = 1.1ms 10000 times kmalloc(16) = 2.4ms kfree() = 1.2ms 10000 times kmalloc(32) = 2.4ms kfree() = 1.2ms 10000 times kmalloc(64) = 2.6ms kfree() = 1.4ms 10000 times kmalloc(128) = 2.8ms kfree() = 1.9ms 10000 times kmalloc(256) = 3ms kfree() = 2ms 10000 times kmalloc(512) = 3.4ms kfree() = 2.1ms 10000 times kmalloc(1024) = 3.9ms kfree() = 2.4ms 10000 times kmalloc(2048) = 4.1ms kfree() = 2.6ms 10000 times kmalloc(4096) = 4.8ms kfree() = 3.5ms 2. Kmalloc: alloc/free test 10000 times kmalloc(8)/kfree = 3ms 10000 times kmalloc(16)/kfree = 3.1ms 10000 times kmalloc(32)/kfree = 3.1ms 10000 times kmalloc(64)/kfree = 3.1ms 10000 times kmalloc(128)/kfree = 3.2ms 10000 times kmalloc(256)/kfree = 3.3ms 10000 times kmalloc(512)/kfree = 3.3ms 10000 times kmalloc(1024)/kfree = 3.4ms 10000 times kmalloc(2048)/kfree = 3.4ms 10000 times kmalloc(4096)/kfree = 3.5ms base line 1. Repeatedly allocate then free test 10000 times kmalloc(8) = 2.4ms kfree() = 1.1ms 10000 times kmalloc(16) = 2.5ms kfree() = 1.1ms 10000 times kmalloc(32) = 2.5ms kfree() = 1.1ms 10000 times kmalloc(64) = 2.7ms kfree() = 1.4ms 10000 times kmalloc(128) = 2.9ms kfree() = 1.9ms 10000 times kmalloc(256) = 3.1ms kfree() = 2ms 10000 times kmalloc(512) = 3.4ms kfree() = 2.1ms 10000 times kmalloc(1024) = 3.9ms kfree() = 2.4ms 10000 times kmalloc(2048) = 4.2ms kfree() = 2.5ms 10000 times kmalloc(4096) = 4.9ms kfree() = 3.2ms 2. Alloc/Free test 10000 times kmalloc(8)/kfree = 3ms 10000 times kmalloc(16)/kfree = 3.1ms 10000 times kmalloc(32)/kfree = 3.1ms 10000 times kmalloc(64)/kfree = 3.1ms 10000 times kmalloc(128)/kfree = 3.2ms 10000 times kmalloc(256)/kfree = 3.2ms 10000 times kmalloc(512)/kfree = 3.2ms 10000 times kmalloc(1024)/kfree = 3.3ms 10000 times kmalloc(2048)/kfree = 3.3ms 10000 times kmalloc(4096)/kfree = 3.3ms - 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/
Powered by blists - more mailing lists