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: Wed, 03 Feb 2016 16:42:37 -0500 From: Waiman Long <waiman.long@....com> To: Ling Ma <ling.ma.program@...il.com> CC: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, Ling <ling.ml@...baba-inc.com> Subject: Re: [RFC PATCH] alispinlock: acceleration from lock integration on multi-core platform On 02/02/2016 11:40 PM, Ling Ma wrote: > Longman, > > The attachment include user space code(thread.c), and kernel > patch(ali_work_queue.patch) based on 4.3.0-rc4, > we replaced all original spinlock (list_lock) in slab.h/c with the > new mechanism. > > The thread.c in user space caused lots of hot kernel spinlock from > __kmalloc and kfree, > perf top -d1 shows ~25% before ali_work_queue.patch,after appending > this patch , > the synchronous operation consumption from __kmalloc and kfree is > reduced from 25% to ~15% on Intel E5-2699V3 > (we also observed the output from user space code (thread.c) is > improved clearly) I have 2 major comments here. First of all, you should break up your patch into smaller ones. Large patch like the one in the tar ball is hard to review. Secondly, you are modifying over 1000 lines of code in mm/slab.c with some modest increase in performance. That can be hard to justify. Maybe you should find other use cases that involve less changes, but still have noticeable performance improvement. That will make it easier to be accepted. Cheers, Longman
Powered by blists - more mailing lists