From: Waiman Long <waiman.long@hpe.com>
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
Date: Fri, 15 Apr 2016 13:37:09 -0400 [thread overview]
Message-ID: <571126C5.3030603@hpe.com> (raw)
In-Reply-To: <1460693133-22100-1-git-send-email-ling.ma.program@gmail.com>
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
prev parent reply other threads:[~2016-04-15 17:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-15 4:05 [RFC PATCH] aliworkqueue: Adaptive lock integration on multi-core platform ling.ma.program
2016-04-15 17:37 ` Waiman Long [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=571126C5.3030603@hpe.com \
--to=waiman.long@hpe.com \
--cc=akpm@linux-foundation.org \
--cc=ling.ma.program@gmail.com \
--cc=ling.ml@alibaba-inc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.