DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: Phil Yang <phil.yang@arm.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	 Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	hemant.agrawal@nxp.com,
	 Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	Gavin Hu <gavin.hu@arm.com>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH v1 0/3] MCS queued lock implementation
Date: Wed, 5 Jun 2019 18:29:56 +0200	[thread overview]
Message-ID: <CAJFAV8y8e7p9881pFYU8ZebKayHwAxe2CvBRhZ-nDXpgFzQXUQ@mail.gmail.com> (raw)
In-Reply-To: <1559750328-22377-1-git-send-email-phil.yang@arm.com>

On Wed, Jun 5, 2019 at 6:00 PM Phil Yang <phil.yang@arm.com> wrote:

> This patch set added MCS lock library and its unit test.
>
> The MCS lock (proposed by JOHN M. MELLOR-CRUMMEY and MICHAEL L. SCOTT)
> provides
> scalability by spinning on a CPU/thread local variable which avoids
> expensive
> cache bouncings. It provides fairness by maintaining a list of acquirers
> and
> passing the lock to each CPU/thread in the order they acquired the lock.
>
> References:
> 1.
> http://web.mit.edu/6.173/www/currentsemester/readings/R06-scalable-synchronization-1991.pdf
> 2. https://lwn.net/Articles/590243/
>
> Mirco-benchmarking result:
>
> ------------------------------------------------------------------------------------------------
> MCS lock                      | spinlock                       | ticket
> lock
>
> ------------------------------+--------------------------------+--------------------------------
> Test with lock on 13 cores... |  Test with lock on 14 cores... |  Test
> with lock on 14 cores...
> Core [15] Cost Time = 22426 us|  Core [14] Cost Time = 47974 us|  Core
> [14] cost time = 66761 us
> Core [16] Cost Time = 22382 us|  Core [15] Cost Time = 46979 us|  Core
> [15] cost time = 66766 us
> Core [17] Cost Time = 22294 us|  Core [16] Cost Time = 46044 us|  Core
> [16] cost time = 66761 us
> Core [18] Cost Time = 22412 us|  Core [17] Cost Time = 28793 us|  Core
> [17] cost time = 66767 us
> Core [19] Cost Time = 22407 us|  Core [18] Cost Time = 48349 us|  Core
> [18] cost time = 66758 us
> Core [20] Cost Time = 22436 us|  Core [19] Cost Time = 19381 us|  Core
> [19] cost time = 66766 us
> Core [21] Cost Time = 22414 us|  Core [20] Cost Time = 47914 us|  Core
> [20] cost time = 66763 us
> Core [22] Cost Time = 22405 us|  Core [21] Cost Time = 48333 us|  Core
> [21] cost time = 66766 us
> Core [23] Cost Time = 22435 us|  Core [22] Cost Time = 38900 us|  Core
> [22] cost time = 66749 us
> Core [24] Cost Time = 22401 us|  Core [23] Cost Time = 45374 us|  Core
> [23] cost time = 66765 us
> Core [25] Cost Time = 22408 us|  Core [24] Cost Time = 16121 us|  Core
> [24] cost time = 66762 us
> Core [26] Cost Time = 22380 us|  Core [25] Cost Time = 42731 us|  Core
> [25] cost time = 66768 us
> Core [27] Cost Time = 22395 us|  Core [26] Cost Time = 29439 us|  Core
> [26] cost time = 66768 us
>                               |  Core [27] Cost Time = 38071 us|  Core
> [27] cost time = 66767 us
>
> ------------------------------+--------------------------------+--------------------------------
> Total Cost Time = 291195 us   |  Total Cost Time = 544403 us   |  Total
> cost time = 934687 us
>
> ------------------------------------------------------------------------------------------------
>

Had a quick look, interesting.

Quick comments:
- your numbers are for 13 cores, while the other are for 14, what is the
reason?
- do we need per architecture header? all I can see is generic code, we
might as well directly put rte_mcslock.h in the common/include directory.
- could we replace the current spinlock with this approach? is this more
expensive than spinlock on lowly contended locks? is there a reason we want
to keep all these approaches? we could have now 3 lock implementations.
- do we need to write the authors names in full capitalized version? it
seems like you are shouting :-)


-- 
David Marchand

  parent reply	other threads:[~2019-06-05 16:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 15:58 Phil Yang
2019-06-05 15:58 ` [dpdk-dev] [PATCH v1 1/3] eal/mcslock: add mcs " Phil Yang
2019-07-05  9:56   ` [dpdk-dev] [PATCH v2 0/3] MCS " Phil Yang
2019-07-05  9:56     ` [dpdk-dev] [PATCH v2 1/3] eal/mcslock: add mcs " Phil Yang
2019-07-05  9:56     ` [dpdk-dev] [PATCH v2 2/3] eal/mcslock: use generic msc queued lock on all arch Phil Yang
2019-07-05  9:56     ` [dpdk-dev] [PATCH v2 3/3] test/mcslock: add mcs queued lock unit test Phil Yang
2019-07-05 10:27   ` [dpdk-dev] [PATCH v3 0/3] MCS queued lock implementation Phil Yang
2019-07-05 10:27     ` [dpdk-dev] [PATCH v3 1/3] eal/mcslock: add mcs " Phil Yang
2019-07-05 10:27     ` [dpdk-dev] [PATCH v3 2/3] eal/mcslock: use generic msc queued lock on all arch Phil Yang
2019-07-05 10:27     ` [dpdk-dev] [PATCH v3 3/3] test/mcslock: add mcs queued lock unit test Phil Yang
2019-07-07 21:49     ` [dpdk-dev] [PATCH v3 0/3] MCS queued lock implementation Thomas Monjalon
2019-06-05 15:58 ` [dpdk-dev] [PATCH v1 2/3] eal/mcslock: use generic msc queued lock on all arch Phil Yang
2019-06-05 15:58 ` [dpdk-dev] [PATCH v1 3/3] test/mcslock: add mcs queued lock unit test Phil Yang
2019-06-06 13:42   ` Ananyev, Konstantin
2019-06-07  5:27     ` Honnappa Nagarahalli
2019-06-10 16:36       ` Phil Yang (Arm Technology China)
2019-06-05 16:29 ` David Marchand [this message]
2019-06-05 19:59   ` [dpdk-dev] [PATCH v1 0/3] MCS queued lock implementation Honnappa Nagarahalli
2019-06-06 10:17   ` Phil Yang (Arm Technology China)
2019-06-05 16:47 ` Stephen Hemminger
2019-06-05 20:48   ` Honnappa Nagarahalli
2019-06-05 17:35 ` Thomas Monjalon
2019-07-04 20:12 ` Thomas Monjalon
2019-07-05 10:33   ` Phil Yang (Arm Technology China)

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=CAJFAV8y8e7p9881pFYU8ZebKayHwAxe2CvBRhZ-nDXpgFzQXUQ@mail.gmail.com \
    --to=david.marchand@redhat.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=dev@dpdk.org \
    --cc=gavin.hu@arm.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=nd@arm.com \
    --cc=phil.yang@arm.com \
    --cc=thomas@monjalon.net \
    /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 NNTP newsgroup(s).