public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "马凌(彦军)" <ling.ml@antfin.com>
To: <fweimer@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>,
	Szabolcs Nagy <Szabolcs.Nagy@arm.com>
Cc: libc-alpha <libc-alpha@sourceware.org>,
	"Xiao, Wei3" <wei3.xiao@intel.com>, nd <nd@arm.com>,
	"ling.ma.program" <ling.ma.program@gmail.com>
Subject: Re: [PATCH] NUMA spinlock [BZ #23962]
Date: Thu, 10 Jan 2019 13:18:00 -0000	[thread overview]
Message-ID: <3A1F9E3E-7654-4E54-AD1F-594CA21E8447@antfin.com> (raw)

Hi Florian,

Thanks for your comments!

We test numa spinlock on 2s-Kunpeng 920 platform ,128 physical arm cores with 256G RAM as below.

$./tst-variable-overhead 
Number of processors: 128, Single thread time 11657100

Number of threads:    2, Total time       33449020, Overhead: 1.43
Number of threads:    4, Total time      135449160, Overhead: 2.90
Number of threads:    8, Total time     1146508900, Overhead: 12.29
Number of threads:   16, Total time     6725395660, Overhead: 36.06
Number of threads:   32, Total time    37197114800, Overhead: 99.72
Number of threads:   64, Total time   501098134360, Overhead: 671.66
Number of threads:  128, Total time  2588795930500, Overhead: 1734.99
Number of threads:  256, Total time 14987969840860, Overhead: 5022.41
Number of threads:  384, Total time 31444706737160, Overhead: 7024.67
Number of threads:  512, Total time 60079858502060, Overhead: 10066.27 

2. numa spinlock
$./tst-numa-variable-overhead
Number of processors: 128, Single thread time 12647780

Number of threads:    2, Total time       36606840, Overhead: 1.45
Number of threads:    4, Total time      115740060, Overhead: 2.29
Number of threads:    8, Total time      604662840, Overhead: 5.98
Number of threads:   16, Total time     2285066760, Overhead: 11.29
Number of threads:   32, Total time     8533264240, Overhead: 21.08
Number of threads:   64, Total time    72671073600, Overhead: 89.78
Number of threads:  128, Total time   287805932560, Overhead: 177.78
Number of threads:  256, Total time   837367226760, Overhead: 258.62
Number of threads:  384, Total time  1954243727660, Overhead: 402.38
Number of threads:  512, Total time  3523015939200, Overhead: 544.04
 
The above data tell us the numa spinlock improve performance upto 17X with 512 threads on arm platform.
And numa spinlock should improve spinlock performance on all multi-socket systems.

Thanks
Ling

在 2019/1/4 上午3:59,“H.J. Lu”<hjl.tools@gmail.com> 写入:

    On Thu, Jan 3, 2019 at 6:52 AM Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
    >
    > On 03/01/2019 05:35, 马凌(彦军) wrote:
    > >      create mode 100644 manual/examples/numa-spinlock.c
    > >      create mode 100644 sysdeps/unix/sysv/linux/numa-spinlock-private.h
    > >      create mode 100644 sysdeps/unix/sysv/linux/numa-spinlock.c
    > >      create mode 100644 sysdeps/unix/sysv/linux/numa-spinlock.h
    > >      create mode 100644 sysdeps/unix/sysv/linux/numa_spinlock_alloc.c
    > >      create mode 100644 sysdeps/unix/sysv/linux/x86/tst-numa-variable-overhead.c
    > >      create mode 100644 sysdeps/unix/sysv/linux/x86/tst-variable-overhead-skeleton.c
    > >      create mode 100644 sysdeps/unix/sysv/linux/x86/tst-variable-overhead.c
    >
    > as far as i can tell the new code is generic
    > (other than the presence of efficient getcpu),
    > so i think the test should be generic too.
    >
    > >     --- /dev/null
    > >     +++ b/sysdeps/unix/sysv/linux/x86/tst-variable-overhead-skeleton.c
    > >     @@ -0,0 +1,384 @@
    > ...
    > >     +/* Check spinlock overhead with large number threads.  Critical region is
    > >     +   very smmall.  Critical region + spinlock overhead aren't noticeable
    > >     +   when number of threads is small.  When thread number increases,
    > >     +   spinlock overhead become the bottleneck.  It shows up in wall time
    > >     +   of thread execution.  */
    >
    > yeah, this is not easy to do in a generic way, i think
    > even on x86 such measurement is problematic, you don't
    > know what goes on a system (or vm) when the glibc test
    > is running.
    >
    > but doing precise timing is not that important for
    > checking the correctness of the locks, so i think a
    > simplified version can be generic test code.
    
    Here is the updated patch to make tests generic.
    
    -- 
    H.J.
    


             reply	other threads:[~2019-01-10 13:18 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10 13:18 马凌(彦军) [this message]
  -- strict thread matches above, loose matches on Subject: below --
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-03 20:43 ` 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
2019-01-15  4:27   ` 马凌(彦军)

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=3A1F9E3E-7654-4E54-AD1F-594CA21E8447@antfin.com \
    --to=ling.ml@antfin.com \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=ling.ma.program@gmail.com \
    --cc=nd@arm.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).