| 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
| ||
|
Message-ID: <20080403082650.GA20132@wotan.suse.de> Date: Thu, 3 Apr 2008 10:26:51 +0200 From: Nick Piggin <npiggin@...e.de> To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> Cc: Pekka Enberg <penberg@...helsinki.fi>, Linux Memory Management List <linux-mm@...ck.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Christoph Lameter <clameter@....com> Subject: Re: [rfc] SLQB: YASA On Thu, Apr 03, 2008 at 05:17:39PM +0900, KOSAKI Motohiro wrote: > Hi > > > > Why is this not a patch set against SLUB? > > > > It's a completely different design of the core allocator algorithms > > really. > > > > It probably looks quite similar because I started with slub.c, but > > really is just the peripheral supporting code and structure. I'm never > > intending to try to go through the pain of incrementally changing SLUB > > into SLQB. If SLQB is found to be a good idea, then it could maybe get > > merged. > > Do you have performance mesurement result? > I hope see it if possible. > > Thanks! :) Nothing really interesting, unfortunately. I have run some tests on various microbenchmarks like tbench and things like that. But I don't have many good ideas for more meaningful tests where slab allocation performance is critial. Any suggestions? :) Thanks, Nick -- 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