Message-ID: <571126C5.3030603@hpe.com>
Date: Fri, 15 Apr 2016 13:37:09 -0400
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.program@gmail.com>
CC: <linux-kernel@vger.kernel.org>, <peterz@infradead.org>,
        <akpm@linux-foundation.org>, <mingo@redhat.com>,
        <ling.ml@alibaba-inc.com>
Subject: Re: [RFC PATCH] aliworkqueue: Adaptive lock integration on multi-core
 platform
References: <y> <1460693133-22100-1-git-send-email-ling.ma.program@gmail.com>
In-Reply-To: <1460693133-22100-1-git-send-email-ling.ma.program@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2016 17:37:15.2498 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0310
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2146
Lines: 51

On 04/15/2016 12:05 AM, ling.ma.program@gmail.com wrote:
> From: Ma Ling<ling.ml@alibaba-inc.com>
>
> Wire-latency(RC delay) dominate modern computer performance,
> conventional serialized works cause cache line ping-pong seriously,
> the process spend lots of time and power to complete.
> specially on multi-core platform.
>
> However if the serialized works are sent to one core and executed
> ONLY when contention happens, that can save much time and power,
> because all shared data are located in private cache of one core.
> We call the mechanism as Adaptive Lock Integration.
> (ali workqueue)
>
> The new code is based on qspinlock and implement Lock Integration,
> when user space application cause the bottle neck from kernel spinlock
> the new mechanism could improve performance up to 1.65x for
> https://lkml.org/lkml/2016/2/4/48 or
> http://lkml.iu.edu/hypermail/linux/kernel/1602.0/03745.html
> and 2.79x for https://lkml.org/lkml/2016/4/4/848 respectively.
>
> And additional changes on Makefile/Kconfig are made to enable compiling of
> this feature on x86 platform.
>
> Signed-off-by: Ma Ling<ling.ml@alibaba-inc.com>
> ---
> The patch is based on https://lkml.org/lkml/2015/12/31/20,
> in this version we append init function and fix function name.
>
>   arch/x86/Kconfig              |    1 +
>   include/linux/aliworkqueue.h  |   34 ++++++++++++++
>   kernel/Kconfig.locks          |    7 +++
>   kernel/locking/Makefile       |    1 +
>   kernel/locking/aliworkqueue.c |   97 +++++++++++++++++++++++++++++++++++++++++
>   5 files changed, 140 insertions(+), 0 deletions(-)
>   create mode 100644 include/linux/aliworkqueue.h
>   create mode 100644 kernel/locking/aliworkqueue.c
>
>

As I said before, you need a use case within the kernel to demonstrate 
its usefulness. The Linux kernel community will not accept code that 
isn't used anywhere.

A major problem to convert regular locking code to using the 
aliworkqueue is that it requires rather significant code changes. So you 
really need a good use case where you can show the performance benefit 
is much greater the cost of making the conversion.

Cheers,
Longman