Re: 转发：[PATCH] NUMA spinlock [BZ #23962]

["马凌(彦军)" <ling dot ml at antfin dot com>]

在 2019/1/3 下午10:52，“Szabolcs Nagy”<Szabolcs.Nagy@arm.com> 写入:

    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.

Ling: It is good idea, we will try to send generic test case in next version.

Thanks
Ling