This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 转发：[PATCH] NUMA spinlock [BZ #23962]
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: 马凌(彦军) <ling dot ml at antfin dot com>, libc-alpha <libc-alpha at sourceware dot org>, "Lu, Hongjiu" <hongjiu dot lu at intel dot com>, "Xiao, Wei3" <wei3 dot xiao at intel dot com>
- Cc: nd <nd at arm dot com>, ling.ma.program <ling dot ma dot program at gmail dot com>
- Date: Thu, 3 Jan 2019 14:52:42 +0000
- Subject: Re: 转发：[PATCH] NUMA spinlock [BZ #23962]
- References: <20181226025019.38752-1-ling.ma@MacBook-Pro-8.local> <7D8A82D6-6F0A-4860-856A-EB0C8CD13E9C@antfin.com> <0a474516-b8c8-48cf-aeea-e57c77b78cbd.ling.ml@antfin.com> <c7f11fea-371e-4453-b5d0-9b142632aecc.ling.ml@antfin.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.