From: kemi <kemi.wang@intel.com>
To: Ma Ling <ling.ma.program@gmail.com>, libc-alpha@sourceware.org
Cc: hongjiu.lu@intel.com, "ling.ma" <ling.ml@antfin.com>,
Wei Xiao <wei3.xiao@intel.com>
Subject: Re: [PATCH] NUMA spinlock [BZ #23962]
Date: Tue, 15 Jan 2019 02:56:00 -0000 [thread overview]
Message-ID: <a820fbc4-883f-c4f2-d2e4-b55df2817dba@intel.com> (raw)
In-Reply-To: <20181226025019.38752-1-ling.ma@MacBook-Pro-8.local>
On 2018/12/26 ä¸å10:50, Ma Ling wrote:
> From: "ling.ma" <ling.ml@antfin.com>
>
> On multi-socket systems, memory is shared across the entire system.
> Data access to the local socket is much faster than the remote socket
> and data access to the local core is faster than sibling cores on the
> same socket. For serialized workloads with conventional spinlock,
> when there is high spinlock contention between threads, lock ping-pong
> among sockets becomes the bottleneck and threads spend majority of
> their time in spinlock overhead.
>
> On multi-socket systems, the keys to our NUMA spinlock performance
> are to minimize cross-socket traffic as well as localize the serialized
> workload to one core for execution. The basic principles of NUMA
> spinlock are mainly consisted of following approaches, which reduce
> data movement and accelerate critical section, eventually give us
> significant performance improvement.
>
> 1. MCS spinlock
> MCS spinlock help us to reduce the useless lock movement in the
> spinning state. This paper provides a good description for this
> kind of lock:
That's not the truth.
No matter generic spinlock(or x86 version) spinlock has used the way of
test and test_and_set to reduce the useless lock movement in the spinning
state.
See
glibc/nptl/pthread_spin_lock.c
glibc/sysdeps/x86_64/nptl/pthread_spin_lock.S
What MCS-spinlock really helps is to accelerate lock release and lock acquisition
by reducing lots of cache line bouncing.
> NUMA spinlock can greatly speed up critical section on multi-socket
> systems. It should improve spinlock performance on all multi-socket
> systems.
>
This is out-of-question that NUMA spinlock helps a lot in case of heavy lock
contention. But, we should also propose the data for non-contented case and slight
contended case.
It's expected that extra code complexity may degrade lock performance a bit for
slight contended case, I would like to see the data for that.
Also, the lock starvation would be possible if the running core is always busy with
heavy lock contention. More explanation is expected.
next prev parent reply other threads:[~2019-01-15 2:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-26 9:51 Ma Ling
2019-01-03 4:05 ` 马凌(彦军)
[not found] ` <0a474516-b8c8-48cf-aeea-e57c77b78cbd.ling.ml@antfin.com>
2019-01-03 5:35 ` 转发:[PATCH] " 马凌(彦军)
2019-01-03 14:52 ` Szabolcs Nagy
2019-01-03 19:59 ` H.J. Lu
2019-01-05 12:34 ` [PATCH] " Carlos O'Donell
2019-01-05 16:36 ` H.J. Lu
2019-01-07 19:12 ` Florian Weimer
2019-01-07 19:49 ` H.J. Lu
2019-01-10 16:31 ` Carlos O'Donell
2019-01-10 16:32 ` Florian Weimer
2019-01-10 16:41 ` Carlos O'Donell
2019-01-10 17:52 ` Szabolcs Nagy
2019-01-10 19:24 ` Carlos O'Donell
2019-01-11 12:01 ` kemi
2019-01-14 22:45 ` Torvald Riegel
2019-01-15 9:32 ` Florian Weimer
2019-01-15 12:01 ` Torvald Riegel
2019-01-15 12:17 ` Florian Weimer
2019-01-15 12:31 ` Torvald Riegel
2019-01-11 16:24 ` H.J. Lu
2019-01-14 23:03 ` Torvald Riegel
2019-01-04 4:13 ` 转发:[PATCH] " 马凌(彦军)
2019-01-03 20:43 ` [PATCH] " Rich Felker
2019-01-03 20:55 ` H.J. Lu
2019-01-03 21:21 ` Rich Felker
2019-01-03 21:28 ` H.J. Lu
2019-01-14 23:18 ` Torvald Riegel
2019-01-15 2:33 ` kemi
2019-01-15 12:37 ` Torvald Riegel
2019-01-15 16:44 ` Rich Felker
2019-01-17 3:10 ` kemi
2019-02-04 17:23 ` Torvald Riegel
2019-01-14 22:40 ` Torvald Riegel
2019-01-14 23:26 ` Torvald Riegel
2019-01-15 4:47 ` 马凌(彦军)
2019-01-15 2:56 ` kemi [this message]
2019-01-15 4:27 ` 马凌(彦军)
2019-01-10 13:18 马凌(彦军)
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=a820fbc4-883f-c4f2-d2e4-b55df2817dba@intel.com \
--to=kemi.wang@intel.com \
--cc=hongjiu.lu@intel.com \
--cc=libc-alpha@sourceware.org \
--cc=ling.ma.program@gmail.com \
--cc=ling.ml@antfin.com \
--cc=wei3.xiao@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).