[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56B2744D.6080202@hpe.com>
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