From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933166AbcBCVmn (ORCPT <rfc822;w@1wt.eu>);
	Wed, 3 Feb 2016 16:42:43 -0500
Received: from g1t6216.austin.hp.com ([15.73.96.123]:58639 "EHLO
	g1t6216.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756415AbcBCVml (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Feb 2016 16:42:41 -0500
Message-ID: <56B2744D.6080202@hpe.com>
Date: Wed, 03 Feb 2016 16:42:37 -0500
From: Waiman Long <waiman.long@hpe.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Ling Ma <ling.ma.program@gmail.com>
CC: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
        Peter Zijlstra <peterz@infradead.org>, mingo@redhat.com,
        linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
        Ling <ling.ml@alibaba-inc.com>
Subject: Re: [RFC PATCH] alispinlock: acceleration from lock integration on
 multi-core platform
References: <1451549374-30875-1-git-send-email-ling.ma.program@gmail.com> <20160105211834.GR6344@twins.programming.kicks-ass.net> <20160105214227.3a2adcd2@lxorguk.ukuu.org.uk> <20160106081643.GS6344@twins.programming.kicks-ass.net> <20160106082106.GU6373@twins.programming.kicks-ass.net> <20160106112450.6c5ad08b@lxorguk.ukuu.org.uk> <CAOGi=dPhZUiXAWwvrNXY=cPga9F16g2-N=MVVV-Oo-cFnQQyPg@mail.gmail.com> <20160112135016.247c6ca5@lxorguk.ukuu.org.uk> <CAOGi=dOz4ogdt303e6PERuGEcrAazVf_r8YigRjtb5kGm5M0eA@mail.gmail.com> <CAOGi=dPaV+H1eg+YeNj0maogMw9MxEqQJsVrpT_mJa9aLKaRUw@mail.gmail.com> <569E5816.6000909@hpe.com> <CAOGi=dNfmJQbN_0N_SK1AFwRzSqgxBmfAVNyBwkG-TdDYLbhMw@mail.gmail.com>
In-Reply-To: <CAOGi=dNfmJQbN_0N_SK1AFwRzSqgxBmfAVNyBwkG-TdDYLbhMw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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