From: Alex Kogan <hidden> Date: 2021-05-14 20:09:19
Changes from v14:
----------------
- Change the way the main queue is scanned and reordered in
cna_wait_head_or_lock(), based on Peter's suggestion.
In detail: instead of inspecting only one queue node, we now scan
(and move nodes into the secondary queue) as long as the lock
remains busy. This simplified the code quite a bit, as we don't need
to call cna_order_queue() again from cna_lock_handoff().
- Use local_clock() instead of relying on jiffies to decide when to
flush the secondary queue, per Andy's suggestion.
- Use module_param() for numa_spinlock_threshold_ns, so it can be tweaked
at runtime, per Andy's suggestion.
- Reduce the default value for numa_spinlock_threshold_ns to 1ms based on
the comments from Andy and Peter. The performance numbers below include
results with the new default as well as with the value of 10ms, which was
the default threshold in previous revisions of the series.
Summary
-------
Lock throughput can be increased by handing a lock to a waiter on the
same NUMA node as the lock holder, provided care is taken to avoid
starvation of waiters on other NUMA nodes. This patch introduces CNA
(compact NUMA-aware lock) as the slow path for qspinlock. It is
enabled through a configuration option (NUMA_AWARE_SPINLOCKS).
CNA is a NUMA-aware version of the MCS lock. Spinning threads are
organized in two queues, a primary queue for threads running on the same
node as the current lock holder, and a secondary queue for threads
running on other nodes. Threads store the ID of the node on which
they are running in their queue nodes. After acquiring the MCS lock and
before acquiring the spinlock, the MCS lock holder checks whether the next
waiter in the primary queue (if exists) is running on the same NUMA node.
If it is not, that waiter is detached from the main queue and moved into
the tail of the secondary queue. This way, we gradually filter the primary
queue, leaving only waiters running on the same preferred NUMA node. Note
that certain priortized waiters (e.g., in irq and nmi contexts) are
excluded from being moved to the secondary queue. We change the NUMA node
preference after a waiter at the head of the secondary queue spins for a
certain amount of time. We do that by flushing the secondary queue into
the head of the primary queue, effectively changing the preference to the
NUMA node of the waiter at the head of the secondary queue at the time of
the flush.
More details are available at https://arxiv.org/abs/1810.05600.
We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0,
commit 3cf5c8ea3a66, compiled in the default configuration.
'CNA' is the modified kernel with NUMA_AWARE_SPINLOCKS set and
the new default threshold of 1ms for flushing the secondary queue
(numa_spinlock_threshold_ns); 'CNA-10ms' is the same as CNA,
but uses the threshold of 10ms. The speedup is calculated by dividing
the result of 'CNA' and 'CNA-10ms', respectively, by the result
achieved with 'stock'.
#thr stock CNA / speedup CNA-10ms / speedup
1 2.695 (0.108) 2.704 (0.099) / 1.003 2.712 (0.077) / 1.006
2 2.753 (0.187) 2.785 (0.171) / 1.012 2.822 (0.174) / 1.025
4 4.355 (0.139) 4.417 (0.179) / 1.014 4.361 (0.181) / 1.001
8 5.163 (0.119) 7.017 (0.195) / 1.359 7.369 (0.186) / 1.427
16 5.944 (0.134) 9.110 (0.242) / 1.532 9.187 (0.233) / 1.546
32 6.310 (0.082) 9.710 (0.156) / 1.539 9.827 (0.161) / 1.557
36 6.374 (0.112) 9.777 (0.141) / 1.534 9.830 (0.124) / 1.542
72 6.170 (0.139) 9.922 (0.190) / 1.608 9.945 (0.136) / 1.612
108 6.002 (0.089) 9.651 (0.176) / 1.608 9.847 (0.125) / 1.641
142 5.784 (0.079) 9.477 (0.089) / 1.638 9.641 (0.113) / 1.667
The following tables contain throughput results (ops/us) from the same
setup for will-it-scale/open1_threads:
#thr stock CNA / speedup CNA-10ms / speedup
1 0.503 (0.004) 0.501 (0.001) / 0.996 0.503 (0.002) / 1.000
2 0.783 (0.014) 0.773 (0.011) / 0.988 0.774 (0.016) / 0.989
4 1.422 (0.025) 1.398 (0.030) / 0.983 1.403 (0.025) / 0.987
8 1.753 (0.104) 1.641 (0.132) / 0.936 1.675 (0.134) / 0.956
16 1.851 (0.097) 1.760 (0.103) / 0.951 1.774 (0.119) / 0.959
32 0.905 (0.081) 1.708 (0.081) / 1.888 1.738 (0.069) / 1.922
36 0.895 (0.058) 1.726 (0.065) / 1.928 1.735 (0.081) / 1.938
72 0.823 (0.033) 1.610 (0.067) / 1.957 1.647 (0.067) / 2.002
108 0.845 (0.035) 1.588 (0.054) / 1.878 1.740 (0.067) / 2.058
142 0.840 (0.030) 1.546 (0.042) / 1.839 1.740 (0.048) / 2.070
and will-it-scale/lock2_threads:
#thr stock CNA / speedup CNA-10ms / speedup
1 1.551 (0.003) 1.558 (0.006) / 1.005 1.558 (0.003) / 1.005
2 2.722 (0.064) 2.704 (0.063) / 0.993 2.727 (0.058) / 1.002
4 5.286 (0.178) 5.360 (0.151) / 1.014 5.360 (0.135) / 1.014
8 4.115 (0.297) 3.906 (0.383) / 0.949 4.062 (0.366) / 0.987
16 4.119 (0.121) 3.950 (0.131) / 0.959 4.009 (0.132) / 0.973
32 2.508 (0.097) 3.805 (0.106) / 1.517 3.960 (0.091) / 1.579
36 2.457 (0.101) 3.810 (0.072) / 1.551 3.931 (0.106) / 1.600
72 1.913 (0.103) 3.530 (0.070) / 1.845 3.860 (0.078) / 2.018
108 1.891 (0.109) 3.410 (0.079) / 1.803 3.881 (0.097) / 2.052
142 1.752 (0.096) 3.236 (0.080) / 1.847 3.774 (0.078) / 2.155
Our evaluation shows that CNA also improves performance of user
applications that have hot pthread mutexes. Those mutexes are
blocking, and waiting threads park and unpark via the futex
mechanism in the kernel. Given that kernel futex chains, which
are hashed by the mutex address, are each protected by a
chain-specific spin lock, the contention on a user-mode mutex
translates into contention on a kernel level spinlock.
Here are the throughput results (ops/us) for the leveldb ‘readrandom’
benchmark:
#thr stock CNA / speedup CNA-10ms / speedup
1 0.533 (0.011) 0.539 (0.014) / 1.012 0.536 (0.013) / 1.006
2 0.854 (0.022) 0.856 (0.017) / 1.003 0.857 (0.020) / 1.004
4 1.236 (0.028) 1.238 (0.054) / 1.002 1.217 (0.054) / 0.985
8 1.207 (0.117) 1.198 (0.122) / 0.993 1.155 (0.138) / 0.957
16 0.758 (0.055) 1.128 (0.118) / 1.489 1.068 (0.131) / 1.409
32 0.743 (0.027) 1.153 (0.028) / 1.551 1.147 (0.021) / 1.543
36 0.708 (0.027) 1.150 (0.024) / 1.623 1.137 (0.026) / 1.605
72 0.629 (0.016) 1.112 (0.019) / 1.767 1.134 (0.019) / 1.802
108 0.610 (0.012) 1.053 (0.018) / 1.725 1.130 (0.017) / 1.853
142 0.606 (0.013) 1.008 (0.020) / 1.664 1.110 (0.023) / 1.833
Further comments are welcome and appreciated.
Alex Kogan (6):
locking/qspinlock: Rename mcs lock/unlock macros and make them more
generic
locking/qspinlock: Refactor the qspinlock slow path
locking/qspinlock: Introduce CNA into the slow path of qspinlock
locking/qspinlock: Introduce starvation avoidance into CNA
locking/qspinlock: Avoid moving certain threads between waiting queues
in CNA
locking/qspinlock: Introduce the shuffle reduction optimization into
CNA
.../admin-guide/kernel-parameters.txt | 18 +
arch/arm/include/asm/mcs_spinlock.h | 6 +-
arch/x86/Kconfig | 20 +
arch/x86/include/asm/qspinlock.h | 4 +
arch/x86/kernel/alternative.c | 4 +
include/asm-generic/mcs_spinlock.h | 4 +-
kernel/locking/mcs_spinlock.h | 20 +-
kernel/locking/qspinlock.c | 82 +++-
kernel/locking/qspinlock_cna.h | 425 ++++++++++++++++++
kernel/locking/qspinlock_paravirt.h | 2 +-
10 files changed, 562 insertions(+), 23 deletions(-)
create mode 100644 kernel/locking/qspinlock_cna.h
--
2.24.3 (Apple Git-128)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Alex Kogan <hidden> Date: 2021-05-14 20:09:10
Prohibit moving certain threads (e.g., in irq and nmi contexts)
to the secondary queue. Those prioritized threads will always stay
in the primary queue, and so will have a shorter wait time for the lock.
Signed-off-by: Alex Kogan <redacted>
Reviewed-by: Steve Sistare <redacted>
Reviewed-by: Waiman Long <longman@redhat.com>
---
kernel/locking/qspinlock_cna.h | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
From: Alex Kogan <hidden> Date: 2021-05-14 20:09:12
Move some of the code manipulating the spin lock into separate functions.
This would allow easier integration of alternative ways to manipulate
that lock.
Signed-off-by: Alex Kogan <redacted>
Reviewed-by: Steve Sistare <redacted>
Reviewed-by: Waiman Long <longman@redhat.com>
---
kernel/locking/qspinlock.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
From: Alex Kogan <hidden> Date: 2021-05-14 20:09:13
This performance optimization chooses probabilistically to avoid moving
threads from the main queue into the secondary one when the secondary queue
is empty.
It is helpful when the lock is only lightly contended. In particular, it
makes CNA less eager to create a secondary queue, but does not introduce
any extra delays for threads waiting in that queue once it is created.
Signed-off-by: Alex Kogan <redacted>
Reviewed-by: Steve Sistare <redacted>
Reviewed-by: Waiman Long <longman@redhat.com>
---
kernel/locking/qspinlock_cna.h | 39 ++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
From: Alex Kogan <hidden> Date: 2021-05-14 20:09:16
The mcs unlock macro (arch_mcs_lock_handoff) should accept the value to be
stored into the lock argument as another argument. This allows using the
same macro in cases where the value to be stored when passing the lock is
different from 1.
Signed-off-by: Alex Kogan <redacted>
Reviewed-by: Steve Sistare <redacted>
Reviewed-by: Waiman Long <longman@redhat.com>
---
arch/arm/include/asm/mcs_spinlock.h | 6 +++---
include/asm-generic/mcs_spinlock.h | 4 ++--
kernel/locking/mcs_spinlock.h | 18 +++++++++---------
kernel/locking/qspinlock.c | 4 ++--
kernel/locking/qspinlock_paravirt.h | 2 +-
5 files changed, 17 insertions(+), 17 deletions(-)
From: Alex Kogan <hidden> Date: 2021-05-14 20:09:21
In CNA, spinning threads are organized in two queues, a primary queue for
threads running on the same node as the current lock holder, and a
secondary queue for threads running on other nodes. After acquiring the
MCS lock and before acquiring the spinlock, the MCS lock
holder checks whether the next waiter in the primary queue (if exists) is
running on the same NUMA node. If it is not, that waiter is detached from
the main queue and moved into the tail of the secondary queue. This way,
we gradually filter the primary queue, leaving only waiters running on
the same preferred NUMA node. For more details, see
https://arxiv.org/abs/1810.05600.
Note that this variant of CNA may introduce starvation by continuously
passing the lock between waiters in the main queue. This issue will be
addressed later in the series.
Enabling CNA is controlled via a new configuration option
(NUMA_AWARE_SPINLOCKS). By default, the CNA variant is patched in at the
boot time only if we run on a multi-node machine in native environment and
the new config is enabled. (For the time being, the patching requires
CONFIG_PARAVIRT_SPINLOCKS to be enabled as well. However, this should be
resolved once static_call() is available.) This default behavior can be
overridden with the new kernel boot command-line option
"numa_spinlock=on/off" (default is "auto").
Signed-off-by: Alex Kogan <redacted>
Reviewed-by: Steve Sistare <redacted>
Reviewed-by: Waiman Long <longman@redhat.com>
---
.../admin-guide/kernel-parameters.txt | 10 +
arch/x86/Kconfig | 20 ++
arch/x86/include/asm/qspinlock.h | 4 +
arch/x86/kernel/alternative.c | 4 +
kernel/locking/mcs_spinlock.h | 2 +-
kernel/locking/qspinlock.c | 42 ++-
kernel/locking/qspinlock_cna.h | 325 ++++++++++++++++++
7 files changed, 402 insertions(+), 5 deletions(-)
create mode 100644 kernel/locking/qspinlock_cna.h
@@ -3515,6 +3515,16 @@ NUMA balancing. Allowed values are enable and disable+ numa_spinlock= [NUMA, PV_OPS] Select the NUMA-aware variant+ of spinlock. The options are:+ auto - Enable this variant if running on a multi-node+ machine in native environment.+ on - Unconditionally enable this variant.+ off - Unconditionally disable this variant.++ Not specifying this option is equivalent to+ numa_spinlock=auto.+ numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. 'node', 'default' can be specified This can be set from sysctl after boot.
@@ -1564,6 +1564,26 @@ config NUMAOtherwise,youshouldsayN.+configNUMA_AWARE_SPINLOCKS+bool"Numa-aware spinlocks"+depends onNUMA+depends onQUEUED_SPINLOCKS+depends on64BIT+# For now, we depend on PARAVIRT_SPINLOCKS to make the patching work.+# This is awkward, but hopefully would be resolved once static_call()+# is available.+depends onPARAVIRT_SPINLOCKS+defaulty+help+IntroduceNUMA(NonUniformMemoryAccess)awarenessinto+theslowpathofspinlocks.++Inthisvariantofqspinlock,thekernelwilltrytokeepthelock+onthesamenode,thusreducingthenumberofremotecachemisses,+whiletradingsomeoftheshorttermfairnessforbetterperformance.++SayNifyouwantabsolutefirstcomefirstservefairness.+configAMD_NUMAdef_boolyprompt"Old style AMD Opteron NUMA detection"
@@ -0,0 +1,325 @@+/* SPDX-License-Identifier: GPL-2.0 */+#ifndef _GEN_CNA_LOCK_SLOWPATH+#error "do not include this file"+#endif++#include<linux/topology.h>++/*+*ImplementaNUMA-awareversionofMCS(akaCNA,orcompactNUMA-awarelock).+*+*InCNA,spinningthreadsareorganizedintwoqueues,aprimaryqueuefor+*threadsrunningonthesameNUMAnodeasthecurrentlockholder,anda+*secondaryqueueforthreadsrunningonothernodes.Schematically,it+*lookslikethis:+*+*cna_node+*+----------++--------++--------++*|mcs:next|-->|mcs:next|-->...|mcs:next|-->NULL[Primaryqueue]+*|mcs:locked|-.+--------++--------++*+----------+|+*`----------------------.+*v+*+--------++--------++*|mcs:next|-->...|mcs:next|[Secondaryqueue]+*+--------++--------++*^|+*`--------------------'+*+*N.B.locked:=1ifsecondaryqueueisabsent.Otherwise,itcontainsthe+*encodedpointertothetailofthesecondaryqueue,whichisorganizedasa+*circularlist.+*+*AfteracquiringtheMCSlockandbeforeacquiringthespinlock,theMCSlock+*holdercheckswhetherthenextwaiterintheprimaryqueue(ifexists)is+*runningonthesameNUMAnode.Ifitisnot,thatwaiterisdetachedfromthe+*mainqueueandmovedintothetailofthesecondaryqueue.Thisway,we+*graduallyfiltertheprimaryqueue,leavingonlywaitersrunningonthesame+*preferredNUMAnode.+*+*Formoredetails,seehttps://arxiv.org/abs/1810.05600.+*+*Authors:AlexKogan<alex.kogan@oracle.com>+*DaveDice<dave.dice@oracle.com>+*/++structcna_node{+structmcs_spinlockmcs;+u16numa_node;+u16real_numa_node;+u32encoded_tail;/* self */+};++staticvoid__initcna_init_nodes_per_cpu(unsignedintcpu)+{+structmcs_spinlock*base=per_cpu_ptr(&qnodes[0].mcs,cpu);+intnuma_node=cpu_to_node(cpu);+inti;++for(i=0;i<MAX_NODES;i++){+structcna_node*cn=(structcna_node*)grab_mcs_node(base,i);++cn->real_numa_node=numa_node;+cn->encoded_tail=encode_tail(cpu,i);+/*+*makesure@encoded_tailisnotconfusedwithothervalid+*valuesfor@locked(0or1)+*/+WARN_ON(cn->encoded_tail<=1);+}+}++staticint__initcna_init_nodes(void)+{+unsignedintcpu;++/*+*thiswillbreakon32bitarchitectures,sowerestrict+*theuseofCNAto64bitonly(seearch/x86/Kconfig)+*/+BUILD_BUG_ON(sizeof(structcna_node)>sizeof(structqnode));+/* we store an ecoded tail word in the node's @locked field */+BUILD_BUG_ON(sizeof(u32)>sizeof(unsignedint));++for_each_possible_cpu(cpu)+cna_init_nodes_per_cpu(cpu);++return0;+}++static__always_inlinevoidcna_init_node(structmcs_spinlock*node)+{+structcna_node*cn=(structcna_node*)node;++cn->numa_node=cn->real_numa_node;+}++/*+*cna_splice_head--splicetheentiresecondaryqueueontotheheadofthe+*primaryqueue.+*+*ReturnsthenewprimaryheadnodeorNULLonfailure.+*/+staticstructmcs_spinlock*+cna_splice_head(structqspinlock*lock,u32val,+structmcs_spinlock*node,structmcs_spinlock*next)+{+structmcs_spinlock*head_2nd,*tail_2nd;+u32new;++tail_2nd=decode_tail(node->locked);+head_2nd=tail_2nd->next;++if(next){+/*+*Iftheprimaryqueueisnotempty,theprimarytaildoesn't+*needtochangeandwecansimplylinkthesecondarytailto+*theoldprimaryhead.+*/+tail_2nd->next=next;+}else{+/*+*Whentheprimaryqueueisempty,thesecondarytailbecomes+*theprimarytail.+*/++/*+*Speculativelybreakthesecondaryqueue'scircularlinksuch+*thatwhenthesecondarytailbecomestheprimarytailitall+*worksout.+*/+tail_2nd->next=NULL;++/*+*tail_2nd->next=NULL;old=xchg_tail(lock,tail);+*prev=decode_tail(old);+*try_cmpxchg_release(...);WRITE_ONCE(prev->next,node);+*+*Ifthefollowingcmpxchg()succeeds,ourstoreswillnot+*collide.+*/+new=((structcna_node*)tail_2nd)->encoded_tail|+_Q_LOCKED_VAL;+if(!atomic_try_cmpxchg_release(&lock->val,&val,new)){+/* Restore the secondary queue's circular link. */+tail_2nd->next=head_2nd;+returnNULL;+}+}++/* The primary queue head now is what was the secondary queue head. */+returnhead_2nd;+}++staticinlineboolcna_try_clear_tail(structqspinlock*lock,u32val,+structmcs_spinlock*node)+{+/*+*We'reherebecausetheprimaryqueueisempty;checkthesecondary+*queueforremotewaiters.+*/+if(node->locked>1){+structmcs_spinlock*next;++/*+*Whentherearewaitersonthesecondaryqueue,trytomove+*thembackontotheprimaryqueueandletthemrip.+*/+next=cna_splice_head(lock,val,node,NULL);+if(next){+arch_mcs_lock_handoff(&next->locked,1);+returntrue;+}++returnfalse;+}++/* Both queues are empty. Do what MCS does. */+return__try_clear_tail(lock,val,node);+}++/*+*cna_splice_next--splicethenextnodefromtheprimaryqueueonto+*thesecondaryqueue.+*/+staticvoidcna_splice_next(structmcs_spinlock*node,+structmcs_spinlock*next,+structmcs_spinlock*nnext)+{+/* remove 'next' from the main queue */+node->next=nnext;++/* stick `next` on the secondary queue tail */+if(node->locked<=1){/* if secondary queue is empty */+/* create secondary queue */+next->next=next;+}else{+/* add to the tail of the secondary queue */+structmcs_spinlock*tail_2nd=decode_tail(node->locked);+structmcs_spinlock*head_2nd=tail_2nd->next;++tail_2nd->next=next;+next->next=head_2nd;+}++node->locked=((structcna_node*)next)->encoded_tail;+}++/*+*cna_order_queue-checkwhetherthenextwaiterinthemainqueueison+*thesameNUMAnodeasthelockholder;ifnot,andithasawaiterbehind+*itinthemainqueue,movetheformerontothesecondaryqueue.+*Returns1ifthenextwaiterrunsonthesameNUMAnode;0otherwise.+*/+staticintcna_order_queue(structmcs_spinlock*node)+{+structmcs_spinlock*next=READ_ONCE(node->next);+structcna_node*cn=(structcna_node*)node;+intnuma_node,next_numa_node;++if(!next)+return0;++numa_node=cn->numa_node;+next_numa_node=((structcna_node*)next)->numa_node;++if(next_numa_node!=numa_node){+structmcs_spinlock*nnext=READ_ONCE(next->next);++if(nnext)+cna_splice_next(node,next,nnext);++return0;+}+return1;+}++#define LOCK_IS_BUSY(lock) (atomic_read(&(lock)->val) & _Q_LOCKED_PENDING_MASK)++/* Abuse the pv_wait_head_or_lock() hook to get some work done */+static__always_inlineu32cna_wait_head_or_lock(structqspinlock*lock,+structmcs_spinlock*node)+{+/*+*Tryandputthetimeotherwisespentspinwaitingon+*_Q_LOCKED_PENDING_MASKtousebysortingourlists.+*/+while(LOCK_IS_BUSY(lock)&&!cna_order_queue(node))+cpu_relax();++return0;/* we lied; we didn't wait, go do so now */+}++staticinlinevoidcna_lock_handoff(structmcs_spinlock*node,+structmcs_spinlock*next)+{+u32val=1;++if(node->locked>1){+structcna_node*cn=(structcna_node*)node;++val=node->locked;/* preseve secondary queue */++/*+*Wehavealocalwaiter,eitherrealorfakeone;+*reload@nextincaseitwaschangedbycna_order_queue().+*/+next=node->next;++/*+*PassoverNUMAnodeidofprimaryqueue,tomaintainthe+*preferenceevenifthenextwaiterisonadifferentnode.+*/+((structcna_node*)next)->numa_node=cn->numa_node;+}++arch_mcs_lock_handoff(&next->locked,val);+}++/*+*Constant(boot-paramconfigurable)flagselectingtheNUMA-awarevariant+*ofspinlock.Possiblevalues:-1(off)/0(auto,default)/1(on).+*/+staticintnuma_spinlock_flag;++staticint__initnuma_spinlock_setup(char*str)+{+if(!strcmp(str,"auto")){+numa_spinlock_flag=0;+return1;+}elseif(!strcmp(str,"on")){+numa_spinlock_flag=1;+return1;+}elseif(!strcmp(str,"off")){+numa_spinlock_flag=-1;+return1;+}++return0;+}+__setup("numa_spinlock=",numa_spinlock_setup);++void__cna_queued_spin_lock_slowpath(structqspinlock*lock,u32val);++/*+*SwitchtotheNUMA-friendlyslowpathforspinlockswhenwehave+*multipleNUMAnodesinnativeenvironment,unlesstheuserhas+*overriddenthisdefaultbehaviorbysettingthenuma_spinlockflag.+*/+void__initcna_configure_spin_lock_slowpath(void)+{++if(numa_spinlock_flag<0)+return;++if(numa_spinlock_flag==0&&(nr_node_ids<2||+pv_ops.lock.queued_spin_lock_slowpath!=+native_queued_spin_lock_slowpath))+return;++cna_init_nodes();++pv_ops.lock.queued_spin_lock_slowpath=__cna_queued_spin_lock_slowpath;++pr_info("Enabling CNA spinlock\n");+}
--
2.24.3 (Apple Git-128)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Alex Kogan <hidden> Date: 2021-05-14 20:09:25
Keep track of the time the thread at the head of the secondary queue
has been waiting, and force inter-node handoff once this time passes
a preset threshold. The default value for the threshold (1ms) can be
overridden with the new kernel boot command-line option
"qspinlock.numa_spinlock_threshold_ns".
Signed-off-by: Alex Kogan <redacted>
Reviewed-by: Steve Sistare <redacted>
Reviewed-by: Waiman Long <longman@redhat.com>
---
.../admin-guide/kernel-parameters.txt | 8 ++
kernel/locking/qspinlock_cna.h | 81 +++++++++++++++----
2 files changed, 73 insertions(+), 16 deletions(-)
@@ -4183,6 +4183,14 @@ [KNL] Number of legacy pty's. Overwrites compiled-in default number.+ qspinlock.numa_spinlock_threshold_ns= [NUMA, PV_OPS]+ Set the time threshold in nanoseconds for the+ number of intra-node lock hand-offs before the+ NUMA-aware spinlock is forced to be passed to+ a thread on another NUMA node. Smaller values+ result in a more fair, but less performant spinlock,+ and vice versa. The default value is 1000000 (=1ms).+ quiet [KNL] Disable most log messages r128= [HW,DRM]
@@ -191,8 +214,14 @@ static void cna_splice_next(struct mcs_spinlock *node,/* stick `next` on the secondary queue tail */if(node->locked<=1){/* if secondary queue is empty */+structcna_node*cn=(structcna_node*)node;+/* create secondary queue */next->next=next;++cn->start_time=local_clock();+/* secondary queue is not empty iff start_time != 0 */+WARN_ON(!cn->start_time);}else{/* add to the tail of the secondary queue */structmcs_spinlock*tail_2nd=decode_tail(node->locked);
@@ -240,12 +269,18 @@ static int cna_order_queue(struct mcs_spinlock *node)static__always_inlineu32cna_wait_head_or_lock(structqspinlock*lock,structmcs_spinlock*node){-/*-*Tryandputthetimeotherwisespentspinwaitingon-*_Q_LOCKED_PENDING_MASKtousebysortingourlists.-*/-while(LOCK_IS_BUSY(lock)&&!cna_order_queue(node))-cpu_relax();+structcna_node*cn=(structcna_node*)node;++if(!cn->start_time||!intra_node_threshold_reached(cn)){+/*+*Tryandputthetimeotherwisespentspinwaitingon+*_Q_LOCKED_PENDING_MASKtousebysortingourlists.+*/+while(LOCK_IS_BUSY(lock)&&!cna_order_queue(node))+cpu_relax();+}else{+cn->start_time=FLUSH_SECONDARY_QUEUE;+}return0;/* we lied; we didn't wait, go do so now */}
NUMA balancing.
Allowed values are enable and disable
+ numa_spinlock= [NUMA, PV_OPS] Select the NUMA-aware variant
+ of spinlock. The options are:
+ auto - Enable this variant if running on a multi-node
+ machine in native environment.
+ on - Unconditionally enable this variant.
Is there any reason why the user would explicitly pass the on option
when the auto thing already does the multi-node check? Perhaps strange
numa topologies? Otherwise I would say it's not needed and the fewer
options we give the user for low level locking the better.
quoted hunk
+ off - Unconditionally disable this variant.
+
+ Not specifying this option is equivalent to
+ numa_spinlock=auto.
+
numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
'node', 'default' can be specified
This can be set from sysctl after boot.
Otherwise, you should say N.
+config NUMA_AWARE_SPINLOCKS
+ bool "Numa-aware spinlocks"
+ depends on NUMA
+ depends on QUEUED_SPINLOCKS
+ depends on 64BIT
+ # For now, we depend on PARAVIRT_SPINLOCKS to make the patching work.
+ # This is awkward, but hopefully would be resolved once static_call()
+ # is available.
+ depends on PARAVIRT_SPINLOCKS
We now have static_call() - see 9183c3f9ed7.
+ default y
+ help
+ Introduce NUMA (Non Uniform Memory Access) awareness into
+ the slow path of spinlocks.
+
+ In this variant of qspinlock, the kernel will try to keep the lock
+ on the same node, thus reducing the number of remote cache misses,
+ while trading some of the short term fairness for better performance.
+
+ Say N if you want absolute first come first serve fairness.
This would also need a depends on !PREEMPT_RT, no? Raw spinlocks really want
the determinism.
Thanks,
Davidlohr
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
NUMA balancing.
Allowed values are enable and disable
+ numa_spinlock= [NUMA, PV_OPS] Select the NUMA-aware variant
+ of spinlock. The options are:
+ auto - Enable this variant if running on a multi-node
+ machine in native environment.
+ on - Unconditionally enable this variant.
Is there any reason why the user would explicitly pass the on option
when the auto thing already does the multi-node check? Perhaps strange
numa topologies? Otherwise I would say it's not needed and the fewer
options we give the user for low level locking the better.
I asked Alex to put in a command line option because we may want to
disable it on a multi-socket server if we want to.
quoted
+ off - Unconditionally disable this variant.
+
+ Not specifying this option is equivalent to
+ numa_spinlock=auto.
+
numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
'node', 'default' can be specified
This can be set from sysctl after boot.
Otherwise, you should say N.
+config NUMA_AWARE_SPINLOCKS
+ bool "Numa-aware spinlocks"
+ depends on NUMA
+ depends on QUEUED_SPINLOCKS
+ depends on 64BIT
+ # For now, we depend on PARAVIRT_SPINLOCKS to make the patching
work.
+ # This is awkward, but hopefully would be resolved once
static_call()
+ # is available.
+ depends on PARAVIRT_SPINLOCKS
We now have static_call() - see 9183c3f9ed7.
I agree that it is now time to look at using the static call for
slowpath switching.
quoted
+ default y
+ help
+ Introduce NUMA (Non Uniform Memory Access) awareness into
+ the slow path of spinlocks.
+
+ In this variant of qspinlock, the kernel will try to keep the
lock
+ on the same node, thus reducing the number of remote cache
misses,
+ while trading some of the short term fairness for better
performance.
+
+ Say N if you want absolute first come first serve fairness.
This would also need a depends on !PREEMPT_RT, no? Raw spinlocks
really want
the determinism.
From: Barry Song <hidden> Date: 2021-09-30 09:45:31
We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0,
I assume x5-4 server has the crossbar topology and its numa diameter is
1hop, and all tests were done on this kind of symmetrical topology. Am
I right?
┌─┐ ┌─┐
│ ├─────────────────┤ │
└─┤1 1└┬┘
│ 1 1 │
│ 1 1 │
│ 1 1 │
│ 1 │
│ 1 1 │
│ 1 1 │
│ 1 1 │
┌┼┐1 1 ├─┐
│┼┼─────────────────┤ │
└─┘ └─┘
what if the hardware is using the ring topology and other topologies with
2-hops or even 3-hops such as:
┌─┐ ┌─┐
│ ├─────────────────┤ │
└─┤ └┬┘
│ │
│ │
│ │
│ │
│ │
│ │
│ │
┌┤ ├─┐
│┼┬─────────────────┤ │
└─┘ └─┘
or:
┌───┐ ┌───┐ ┌────┐ ┌─────┐
│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │
├───┼───────┼───┼──────┼────┼──────┼─────┤
│ │ │ │ │ │ │ │
└───┘ └───┘ └────┘ └─────┘
do we need to consider the distances of numa nodes in the secondary
queue? does it still make sense to treat everyone else equal in
secondary queue?
Thanks
barry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Barry Song <hidden> Date: 2021-09-30 10:05:38
+/*
+ * Implement a NUMA-aware version of MCS (aka CNA, or compact NUMA-aware lock).
+ *
+ * In CNA, spinning threads are organized in two queues, a primary queue for
+ * threads running on the same NUMA node as the current lock holder, and a
+ * secondary queue for threads running on other nodes. Schematically, it
+ * looks like this:
+ *
+ * cna_node
+ * +----------+ +--------+ +--------+
+ * |mcs:next | --> |mcs:next| --> ... |mcs:next| --> NULL [Primary queue]
+ * |mcs:locked| -. +--------+ +--------+
+ * +----------+ |
+ * `----------------------.
+ * v
+ * +--------+ +--------+
+ * |mcs:next| --> ... |mcs:next| [Secondary queue]
+ * +--------+ +--------+
+ * ^ |
+ * `--------------------'
+ *
probably not only related with NUMA, it might be also related with cache topology.
For example, one NUMA might has a couple of sub domains, each domain shares some
last level cache. ZEN, Power and some ARM servers all have this kind of topology.
lock synchronization within this smaller range should be much faster. anyway, it
looks like a good start to be aware of numa only for this moment.
Thanks
barry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Waiman Long <hidden> Date: 2021-09-30 16:58:59
On 9/30/21 5:44 AM, Barry Song wrote:
quoted
We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0,
I assume x5-4 server has the crossbar topology and its numa diameter is
1hop, and all tests were done on this kind of symmetrical topology. Am
I right?
┌─┐ ┌─┐
│ ├─────────────────┤ │
└─┤1 1└┬┘
│ 1 1 │
│ 1 1 │
│ 1 1 │
│ 1 │
│ 1 1 │
│ 1 1 │
│ 1 1 │
┌┼┐1 1 ├─┐
│┼┼─────────────────┤ │
└─┘ └─┘
what if the hardware is using the ring topology and other topologies with
2-hops or even 3-hops such as:
┌─┐ ┌─┐
│ ├─────────────────┤ │
└─┤ └┬┘
│ │
│ │
│ │
│ │
│ │
│ │
│ │
┌┤ ├─┐
│┼┬─────────────────┤ │
└─┘ └─┘
or:
┌───┐ ┌───┐ ┌────┐ ┌─────┐
│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │
├───┼───────┼───┼──────┼────┼──────┼─────┤
│ │ │ │ │ │ │ │
└───┘ └───┘ └────┘ └─────┘
do we need to consider the distances of numa nodes in the secondary
queue? does it still make sense to treat everyone else equal in
secondary queue?
The purpose of this patch series is to minimize cacheline transfer from
one numa node to another. Taking the fine grained detail of the numa
topology into account will complicate the code without much performance
benefit from my point of view. Let's keep it simple first. We can always
improve it later on if one can show real benefit of doing so.
Cheers,
Longman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Barry Song <hidden> Date: 2021-09-30 22:58:15
On Fri, Oct 1, 2021 at 5:58 AM Waiman Long [off-list ref] wrote:
On 9/30/21 5:44 AM, Barry Song wrote:
quoted
quoted
We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0,
I assume x5-4 server has the crossbar topology and its numa diameter is
1hop, and all tests were done on this kind of symmetrical topology. Am
I right?
┌─┐ ┌─┐
│ ├─────────────────┤ │
└─┤1 1└┬┘
│ 1 1 │
│ 1 1 │
│ 1 1 │
│ 1 │
│ 1 1 │
│ 1 1 │
│ 1 1 │
┌┼┐1 1 ├─┐
│┼┼─────────────────┤ │
└─┘ └─┘
what if the hardware is using the ring topology and other topologies with
2-hops or even 3-hops such as:
┌─┐ ┌─┐
│ ├─────────────────┤ │
└─┤ └┬┘
│ │
│ │
│ │
│ │
│ │
│ │
│ │
┌┤ ├─┐
│┼┬─────────────────┤ │
└─┘ └─┘
or:
┌───┐ ┌───┐ ┌────┐ ┌─────┐
│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │
├───┼───────┼───┼──────┼────┼──────┼─────┤
│ │ │ │ │ │ │ │
└───┘ └───┘ └────┘ └─────┘
do we need to consider the distances of numa nodes in the secondary
queue? does it still make sense to treat everyone else equal in
secondary queue?
The purpose of this patch series is to minimize cacheline transfer from
one numa node to another. Taking the fine grained detail of the numa
topology into account will complicate the code without much performance
benefit from my point of view. Let's keep it simple first. We can always
improve it later on if one can show real benefit of doing so.
for sure i am not expecting the complex NUMA topology taken into account for
this moment. I am just curious how things will be different if topology isn't a
crossbar with 1-hop only.
when the master queue is empty, the distance of the numa node spinlock will
jump to will affect the performance. but I am not quite sure how much it will
be. just like a disk, bumping back and forth between far cylinders and sectors
might waste a lot of time.
On the other hand, some numa nodes might be very close while some others
might be very far. for example, if one socket has several DIEs, and the machine
has several sockets, cacheline coherence overhead for NUMA nodes of DIEs within
one socket might be much less than that of NUMA nodes which are in different
sockets. I assume maintaining the master/secondary queues need some
overhead especially while the system has many cores and multiple NUMA nodes,
in this case, making neighbor NUMA nodes share one master queue might win.
Anyway, we need a lot of benchmarking on this before we can really do anything
on it. For this moment, ignoring the complicated topology should be a
better way
to start.
From: Alex Kogan <hidden> Date: 2021-09-30 23:52:14
On Sep 30, 2021, at 5:44 AM, Barry Song [off-list ref] wrote:
quoted
We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0,
I assume x5-4 server has the crossbar topology and its numa diameter is
1hop, and all tests were done on this kind of symmetrical topology. Am
I right?
┌─┐ ┌─┐
│ ├─────────────────┤ │
└─┤1 1└┬┘
│ 1 1 │
│ 1 1 │
│ 1 1 │
│ 1 │
│ 1 1 │
│ 1 1 │
│ 1 1 │
┌┼┐1 1 ├─┐
│┼┼─────────────────┤ │
└─┘ └─┘
what if the hardware is using the ring topology and other topologies
For better or worse, CNA is pretty much agnostic to the physical topology.
So it is true that we might do better by transferring NUMA node preference
to a “closer” node, but it would probably require some sophisticated logic
to identify such a node. As discussed on another thread, we are opting
for a simple solution that might be refined later if needed.
Best regards,
— Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Alex Kogan <hidden> Date: 2021-12-13 20:39:18
Hi, all.
A couple of quick updates regarding the patch series.
First, I am working to collect more performance data for the patch.
In particular, I measured up to 14% throughput improvement for RocksDB[1]
and 26% improvement for a few sybench[2] benchmarks. The details appear
below. sybench also has a number of OLTP-like benchmarks; those do not show
sensitivity to CNA -- no improvements, no regressions.
Second, we became aware of the work by researchers at Huawei Dresden
Research Center who verified the correctness of CNA on weak memory
models: https://arxiv.org/pdf/2111.15240.pdf. The authors found the
CNA patch series (with some minor simplifications) to be correct in the
Linux kernel memory model. For further details, please refer to the paper.
=============
The following results are from an Oracle X5-8 server (eight Intel Xeon
E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded cores each). Note
that this system is different from the one I was normally using for testing,
as the latter is going through repairs. Each number represents average
throughput over 25 runs. The standard deviation is also reported in ().
The throughput results (ops/us) for RocksDB (v6.26.0) ‘readrandom’ benchmark:
#thr stock CNA / speedup
1 0.131 (0.004) 0.130 (0.005) / 0.989
2 0.232 (0.005) 0.230 (0.004) / 0.991
4 0.437 (0.008) 0.430 (0.009) / 0.985
8 0.560 (0.015) 0.563 (0.014) / 1.004
16 0.699 (0.017) 0.690 (0.032) / 0.986
32 0.738 (0.029) 0.763 (0.028) / 1.034
64 0.597 (0.014) 0.631 (0.012) / 1.057
72 0.591 (0.010) 0.623 (0.012) / 1.054
144 0.569 (0.010) 0.636 (0.012) / 1.117
216 0.540 (0.008) 0.615 (0.009) / 1.139
286 0.527 (0.005) 0.579 (0.009) / 1.099
The throughput results (events/ms) for sysbench ’threads’ benchmark:
#thr stock CNA / speedup
1 2168.245 (11.715) 2169.734 (8.042) / 1.001
2 1016.283 (48.849) 1097.674 (19.516) / 1.080
4 1220.588 (17.383) 1229.191 (11.928) / 1.007
8 1048.581 (46.102) 1036.614 (13.365) / 0.989
16 804.573 (30.343) 832.324 (26.457) / 1.034
32 799.307 (39.315) 869.813 (9.352) / 1.088
64 688.387 (7.312) 812.554 (19.414) / 1.180
72 681.979 (16.198) 825.458 (8.655) / 1.210
144 606.460 (5.277) 759.814 (7.027) / 1.253
216 580.517 (6.718) 719.856 (8.381) / 1.240
286 527.053 (12.382) 659.322 (12.527) / 1.251
The throughput results (events/ms) for sysbench ’mutex’ benchmark:
1 15.218 (0.064) 14.986 (0.080) / 0.985
2 6.043 (0.953) 6.058 (0.856) / 1.003
4 5.852 (0.132) 5.761 (0.295) / 0.984
8 3.291 (0.054) 3.241 (0.143) / 0.985
16 2.931 (0.036) 3.437 (0.150) / 1.173
32 2.863 (0.058) 3.267 (0.124) / 1.141
64 2.457 (0.099) 3.101 (0.024) / 1.262
72 2.438 (0.060) 3.054 (0.079) / 1.253
144 2.399 (0.042) 3.007 (0.056) / 1.253
216 2.413 (0.033) 2.697 (0.044) / 1.118
286 2.029 (0.033) 2.288 (0.015) / 1.128
Best regards,
— Alex
[1] https://github.com/facebook/rocksdb
[2] https://github.com/akopytov/sysbench
On May 14, 2021, at 4:07 PM, Alex Kogan [off-list ref] wrote:
Changes from v14:
----------------
- Change the way the main queue is scanned and reordered in
cna_wait_head_or_lock(), based on Peter's suggestion.
In detail: instead of inspecting only one queue node, we now scan
(and move nodes into the secondary queue) as long as the lock
remains busy. This simplified the code quite a bit, as we don't need
to call cna_order_queue() again from cna_lock_handoff().
- Use local_clock() instead of relying on jiffies to decide when to
flush the secondary queue, per Andy's suggestion.
- Use module_param() for numa_spinlock_threshold_ns, so it can be tweaked
at runtime, per Andy's suggestion.
- Reduce the default value for numa_spinlock_threshold_ns to 1ms based on
the comments from Andy and Peter. The performance numbers below include
results with the new default as well as with the value of 10ms, which was
the default threshold in previous revisions of the series.
Summary
-------
Lock throughput can be increased by handing a lock to a waiter on the
same NUMA node as the lock holder, provided care is taken to avoid
starvation of waiters on other NUMA nodes. This patch introduces CNA
(compact NUMA-aware lock) as the slow path for qspinlock. It is
enabled through a configuration option (NUMA_AWARE_SPINLOCKS).
CNA is a NUMA-aware version of the MCS lock. Spinning threads are
organized in two queues, a primary queue for threads running on the same
node as the current lock holder, and a secondary queue for threads
running on other nodes. Threads store the ID of the node on which
they are running in their queue nodes. After acquiring the MCS lock and
before acquiring the spinlock, the MCS lock holder checks whether the next
waiter in the primary queue (if exists) is running on the same NUMA node.
If it is not, that waiter is detached from the main queue and moved into
the tail of the secondary queue. This way, we gradually filter the primary
queue, leaving only waiters running on the same preferred NUMA node. Note
that certain priortized waiters (e.g., in irq and nmi contexts) are
excluded from being moved to the secondary queue. We change the NUMA node
preference after a waiter at the head of the secondary queue spins for a
certain amount of time. We do that by flushing the secondary queue into
the head of the primary queue, effectively changing the preference to the
NUMA node of the waiter at the head of the secondary queue at the time of
the flush.
More details are available at https://arxiv.org/abs/1810.05600.
We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0,
commit 3cf5c8ea3a66, compiled in the default configuration.
'CNA' is the modified kernel with NUMA_AWARE_SPINLOCKS set and
the new default threshold of 1ms for flushing the secondary queue
(numa_spinlock_threshold_ns); 'CNA-10ms' is the same as CNA,
but uses the threshold of 10ms. The speedup is calculated by dividing
the result of 'CNA' and 'CNA-10ms', respectively, by the result
achieved with 'stock'.
#thr stock CNA / speedup CNA-10ms / speedup
1 2.695 (0.108) 2.704 (0.099) / 1.003 2.712 (0.077) / 1.006
2 2.753 (0.187) 2.785 (0.171) / 1.012 2.822 (0.174) / 1.025
4 4.355 (0.139) 4.417 (0.179) / 1.014 4.361 (0.181) / 1.001
8 5.163 (0.119) 7.017 (0.195) / 1.359 7.369 (0.186) / 1.427
16 5.944 (0.134) 9.110 (0.242) / 1.532 9.187 (0.233) / 1.546
32 6.310 (0.082) 9.710 (0.156) / 1.539 9.827 (0.161) / 1.557
36 6.374 (0.112) 9.777 (0.141) / 1.534 9.830 (0.124) / 1.542
72 6.170 (0.139) 9.922 (0.190) / 1.608 9.945 (0.136) / 1.612
108 6.002 (0.089) 9.651 (0.176) / 1.608 9.847 (0.125) / 1.641
142 5.784 (0.079) 9.477 (0.089) / 1.638 9.641 (0.113) / 1.667
The following tables contain throughput results (ops/us) from the same
setup for will-it-scale/open1_threads:
#thr stock CNA / speedup CNA-10ms / speedup
1 0.503 (0.004) 0.501 (0.001) / 0.996 0.503 (0.002) / 1.000
2 0.783 (0.014) 0.773 (0.011) / 0.988 0.774 (0.016) / 0.989
4 1.422 (0.025) 1.398 (0.030) / 0.983 1.403 (0.025) / 0.987
8 1.753 (0.104) 1.641 (0.132) / 0.936 1.675 (0.134) / 0.956
16 1.851 (0.097) 1.760 (0.103) / 0.951 1.774 (0.119) / 0.959
32 0.905 (0.081) 1.708 (0.081) / 1.888 1.738 (0.069) / 1.922
36 0.895 (0.058) 1.726 (0.065) / 1.928 1.735 (0.081) / 1.938
72 0.823 (0.033) 1.610 (0.067) / 1.957 1.647 (0.067) / 2.002
108 0.845 (0.035) 1.588 (0.054) / 1.878 1.740 (0.067) / 2.058
142 0.840 (0.030) 1.546 (0.042) / 1.839 1.740 (0.048) / 2.070
and will-it-scale/lock2_threads:
#thr stock CNA / speedup CNA-10ms / speedup
1 1.551 (0.003) 1.558 (0.006) / 1.005 1.558 (0.003) / 1.005
2 2.722 (0.064) 2.704 (0.063) / 0.993 2.727 (0.058) / 1.002
4 5.286 (0.178) 5.360 (0.151) / 1.014 5.360 (0.135) / 1.014
8 4.115 (0.297) 3.906 (0.383) / 0.949 4.062 (0.366) / 0.987
16 4.119 (0.121) 3.950 (0.131) / 0.959 4.009 (0.132) / 0.973
32 2.508 (0.097) 3.805 (0.106) / 1.517 3.960 (0.091) / 1.579
36 2.457 (0.101) 3.810 (0.072) / 1.551 3.931 (0.106) / 1.600
72 1.913 (0.103) 3.530 (0.070) / 1.845 3.860 (0.078) / 2.018
108 1.891 (0.109) 3.410 (0.079) / 1.803 3.881 (0.097) / 2.052
142 1.752 (0.096) 3.236 (0.080) / 1.847 3.774 (0.078) / 2.155
Our evaluation shows that CNA also improves performance of user
applications that have hot pthread mutexes. Those mutexes are
blocking, and waiting threads park and unpark via the futex
mechanism in the kernel. Given that kernel futex chains, which
are hashed by the mutex address, are each protected by a
chain-specific spin lock, the contention on a user-mode mutex
translates into contention on a kernel level spinlock.
Here are the throughput results (ops/us) for the leveldb ‘readrandom’
benchmark:
#thr stock CNA / speedup CNA-10ms / speedup
1 0.533 (0.011) 0.539 (0.014) / 1.012 0.536 (0.013) / 1.006
2 0.854 (0.022) 0.856 (0.017) / 1.003 0.857 (0.020) / 1.004
4 1.236 (0.028) 1.238 (0.054) / 1.002 1.217 (0.054) / 0.985
8 1.207 (0.117) 1.198 (0.122) / 0.993 1.155 (0.138) / 0.957
16 0.758 (0.055) 1.128 (0.118) / 1.489 1.068 (0.131) / 1.409
32 0.743 (0.027) 1.153 (0.028) / 1.551 1.147 (0.021) / 1.543
36 0.708 (0.027) 1.150 (0.024) / 1.623 1.137 (0.026) / 1.605
72 0.629 (0.016) 1.112 (0.019) / 1.767 1.134 (0.019) / 1.802
108 0.610 (0.012) 1.053 (0.018) / 1.725 1.130 (0.017) / 1.853
142 0.606 (0.013) 1.008 (0.020) / 1.664 1.110 (0.023) / 1.833
Further comments are welcome and appreciated.
Alex Kogan (6):
locking/qspinlock: Rename mcs lock/unlock macros and make them more
generic
locking/qspinlock: Refactor the qspinlock slow path
locking/qspinlock: Introduce CNA into the slow path of qspinlock
locking/qspinlock: Introduce starvation avoidance into CNA
locking/qspinlock: Avoid moving certain threads between waiting queues
in CNA
locking/qspinlock: Introduce the shuffle reduction optimization into
CNA
.../admin-guide/kernel-parameters.txt | 18 +
arch/arm/include/asm/mcs_spinlock.h | 6 +-
arch/x86/Kconfig | 20 +
arch/x86/include/asm/qspinlock.h | 4 +
arch/x86/kernel/alternative.c | 4 +
include/asm-generic/mcs_spinlock.h | 4 +-
kernel/locking/mcs_spinlock.h | 20 +-
kernel/locking/qspinlock.c | 82 +++-
kernel/locking/qspinlock_cna.h | 425 ++++++++++++++++++
kernel/locking/qspinlock_paravirt.h | 2 +-
10 files changed, 562 insertions(+), 23 deletions(-)
create mode 100644 kernel/locking/qspinlock_cna.h
--
2.24.3 (Apple Git-128)
From: Alex Kogan <hidden> Date: 2022-04-11 17:12:23
Hi, all.
I’ve got around to collect more performance data with macro-benchmarks
from the LKP suite[1]. Specifically, I measured more than 2.5x improvement
with fsmark and up to nearly 2x improvement with AIM7. Note that similar
improvements have been previously reported by the kernel test robot [2,3],
but it is nice to see that they are reproducible on our system as well.
The details appear below.
Our performance team also evaluated the performance of TPC-C with
Oracle DB on the patched kernel with CNA. The evaluation, carried on a
system equipped with two AMD EPYC 7551 processors, showed
no sensitivity to CNA -- no improvements, no regressions.
=============
The following results are from an Oracle X5-8 server (eight Intel Xeon
E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded cores each). Each
number represents average throughput over 25 runs. The standard deviation
is also reported in (), and it was pretty large in some experiments.
The following results are from the fsmark benchmark (based on the
`fsmark-generic-1brd-1BRD_48G-4M-btrfs-1x-*t-NoSync-24G` config).
The reported numbers represent `files-per-sec`.
num-threads stock CNA / speedup
1 400.216 (7.399) 403.212 (7.169) / 1.007
2 784.484 (13.809) 778.196 (22.699) / 0.992
4 1153.792 (54.699) 1130.140 (53.823) / 0.980
8 1240.424 (160.453) 1287.532 (169.659) / 1.038
16 1440.720 (182.555) 1489.288 (148.604) / 1.034
32 1600.432 (59.944) 1860.652 (212.971) / 1.163
64 1169.740 (40.815) 3027.680 (142.349) / 2.588
72 1174.240 (39.261) 2682.560 (543.690) / 2.285
144 1164.296 (42.441) 2842.684 (400.664) / 2.442
216 1174.312 (38.392) 2445.168 (575.668) / 2.082
286 1174.732 (52.430) 2598.444 (468.615) / 2.212
We also experimented with another config
(`fsmark-generic-1brd-1BRD_48G-4M-btrfs-1x-*t-fsyncBeforeClose-24G`)
and measured more modest, yet robust improvement:
num-threads stock CNA / speedup
1 177.304 (3.659) 178.596 (3.299) / 1.007
2 345.260 (8.398) 349.384 (5.706) / 1.012
4 647.292 (14.982) 648.164 (11.286) / 1.001
8 1008.304 (46.342) 1007.108 (37.765) / 0.999
16 1116.652 (57.816) 1150.752 (49.005) / 1.031
32 1229.760 (84.932) 1346.132 (80.935) / 1.095
64 981.564 (59.533) 1313.992 (74.971) / 1.339
72 995.180 (59.228) 1266.660 (63.287) / 1.273
144 978.448 (69.581) 1290.336 (43.065) / 1.319
216 1011.880 (60.154) 1310.524 (61.631) / 1.295
286 985.164 (67.016) 1305.244 (63.735) / 1.325
The following results are from the AIM7 benchmark (based on the
`aim7-fs-raid-4BRD_12G-btrfs-*-RAID0-disk_rr` config). Here we vary
the load, and measure performance in `jobs-per-minute` units. Due to time
limitations, each experiment was repeated only 7 times.
load stock CNA / speedup
2 965.631 (1.696) 963.969 (0.965) / 0.998
20 7901.647 (116.671) 8256.576 (93.362) / 1.045
100 16409.144 (280.828) 23380.819 (279.365) / 1.425
500 20355.541 (353.862) 34281.836 (873.357) / 1.684
1000 20733.947 (507.388) 36546.829 (695.273) / 1.763
1500 21570.639 (499.205) 37078.249 (806.669) / 1.719
3000 22068.761 (415.813) 36649.144 (1219.638) / 1.661
9000 19551.681 (337.232) 37998.464 (687.059) / 1.943
Best regards,
— Alex
[1] https://github.com/intel/lkp-tests.git
[2] https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/HGVOCYDEE5KTLYPTAFBD2RXDQOCDPFUJ/
[3] https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/DNMEQPXJRQY2IKHZ3ERGRY6TUPWDTFUN/
On May 14, 2021, at 4:07 PM, Alex Kogan [off-list ref] wrote:
Changes from v14:
----------------
- Change the way the main queue is scanned and reordered in
cna_wait_head_or_lock(), based on Peter's suggestion.
In detail: instead of inspecting only one queue node, we now scan
(and move nodes into the secondary queue) as long as the lock
remains busy. This simplified the code quite a bit, as we don't need
to call cna_order_queue() again from cna_lock_handoff().
- Use local_clock() instead of relying on jiffies to decide when to
flush the secondary queue, per Andy's suggestion.
- Use module_param() for numa_spinlock_threshold_ns, so it can be tweaked
at runtime, per Andy's suggestion.
- Reduce the default value for numa_spinlock_threshold_ns to 1ms based on
the comments from Andy and Peter. The performance numbers below include
results with the new default as well as with the value of 10ms, which was
the default threshold in previous revisions of the series.
Summary
-------
Lock throughput can be increased by handing a lock to a waiter on the
same NUMA node as the lock holder, provided care is taken to avoid
starvation of waiters on other NUMA nodes. This patch introduces CNA
(compact NUMA-aware lock) as the slow path for qspinlock. It is
enabled through a configuration option (NUMA_AWARE_SPINLOCKS).
CNA is a NUMA-aware version of the MCS lock. Spinning threads are
organized in two queues, a primary queue for threads running on the same
node as the current lock holder, and a secondary queue for threads
running on other nodes. Threads store the ID of the node on which
they are running in their queue nodes. After acquiring the MCS lock and
before acquiring the spinlock, the MCS lock holder checks whether the next
waiter in the primary queue (if exists) is running on the same NUMA node.
If it is not, that waiter is detached from the main queue and moved into
the tail of the secondary queue. This way, we gradually filter the primary
queue, leaving only waiters running on the same preferred NUMA node. Note
that certain priortized waiters (e.g., in irq and nmi contexts) are
excluded from being moved to the secondary queue. We change the NUMA node
preference after a waiter at the head of the secondary queue spins for a
certain amount of time. We do that by flushing the secondary queue into
the head of the primary queue, effectively changing the preference to the
NUMA node of the waiter at the head of the secondary queue at the time of
the flush.
More details are available at https://arxiv.org/abs/1810.05600.
We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0,
commit 3cf5c8ea3a66, compiled in the default configuration.
'CNA' is the modified kernel with NUMA_AWARE_SPINLOCKS set and
the new default threshold of 1ms for flushing the secondary queue
(numa_spinlock_threshold_ns); 'CNA-10ms' is the same as CNA,
but uses the threshold of 10ms. The speedup is calculated by dividing
the result of 'CNA' and 'CNA-10ms', respectively, by the result
achieved with 'stock'.
#thr stock CNA / speedup CNA-10ms / speedup
1 2.695 (0.108) 2.704 (0.099) / 1.003 2.712 (0.077) / 1.006
2 2.753 (0.187) 2.785 (0.171) / 1.012 2.822 (0.174) / 1.025
4 4.355 (0.139) 4.417 (0.179) / 1.014 4.361 (0.181) / 1.001
8 5.163 (0.119) 7.017 (0.195) / 1.359 7.369 (0.186) / 1.427
16 5.944 (0.134) 9.110 (0.242) / 1.532 9.187 (0.233) / 1.546
32 6.310 (0.082) 9.710 (0.156) / 1.539 9.827 (0.161) / 1.557
36 6.374 (0.112) 9.777 (0.141) / 1.534 9.830 (0.124) / 1.542
72 6.170 (0.139) 9.922 (0.190) / 1.608 9.945 (0.136) / 1.612
108 6.002 (0.089) 9.651 (0.176) / 1.608 9.847 (0.125) / 1.641
142 5.784 (0.079) 9.477 (0.089) / 1.638 9.641 (0.113) / 1.667
The following tables contain throughput results (ops/us) from the same
setup for will-it-scale/open1_threads:
#thr stock CNA / speedup CNA-10ms / speedup
1 0.503 (0.004) 0.501 (0.001) / 0.996 0.503 (0.002) / 1.000
2 0.783 (0.014) 0.773 (0.011) / 0.988 0.774 (0.016) / 0.989
4 1.422 (0.025) 1.398 (0.030) / 0.983 1.403 (0.025) / 0.987
8 1.753 (0.104) 1.641 (0.132) / 0.936 1.675 (0.134) / 0.956
16 1.851 (0.097) 1.760 (0.103) / 0.951 1.774 (0.119) / 0.959
32 0.905 (0.081) 1.708 (0.081) / 1.888 1.738 (0.069) / 1.922
36 0.895 (0.058) 1.726 (0.065) / 1.928 1.735 (0.081) / 1.938
72 0.823 (0.033) 1.610 (0.067) / 1.957 1.647 (0.067) / 2.002
108 0.845 (0.035) 1.588 (0.054) / 1.878 1.740 (0.067) / 2.058
142 0.840 (0.030) 1.546 (0.042) / 1.839 1.740 (0.048) / 2.070
and will-it-scale/lock2_threads:
#thr stock CNA / speedup CNA-10ms / speedup
1 1.551 (0.003) 1.558 (0.006) / 1.005 1.558 (0.003) / 1.005
2 2.722 (0.064) 2.704 (0.063) / 0.993 2.727 (0.058) / 1.002
4 5.286 (0.178) 5.360 (0.151) / 1.014 5.360 (0.135) / 1.014
8 4.115 (0.297) 3.906 (0.383) / 0.949 4.062 (0.366) / 0.987
16 4.119 (0.121) 3.950 (0.131) / 0.959 4.009 (0.132) / 0.973
32 2.508 (0.097) 3.805 (0.106) / 1.517 3.960 (0.091) / 1.579
36 2.457 (0.101) 3.810 (0.072) / 1.551 3.931 (0.106) / 1.600
72 1.913 (0.103) 3.530 (0.070) / 1.845 3.860 (0.078) / 2.018
108 1.891 (0.109) 3.410 (0.079) / 1.803 3.881 (0.097) / 2.052
142 1.752 (0.096) 3.236 (0.080) / 1.847 3.774 (0.078) / 2.155
Our evaluation shows that CNA also improves performance of user
applications that have hot pthread mutexes. Those mutexes are
blocking, and waiting threads park and unpark via the futex
mechanism in the kernel. Given that kernel futex chains, which
are hashed by the mutex address, are each protected by a
chain-specific spin lock, the contention on a user-mode mutex
translates into contention on a kernel level spinlock.
Here are the throughput results (ops/us) for the leveldb ‘readrandom’
benchmark:
#thr stock CNA / speedup CNA-10ms / speedup
1 0.533 (0.011) 0.539 (0.014) / 1.012 0.536 (0.013) / 1.006
2 0.854 (0.022) 0.856 (0.017) / 1.003 0.857 (0.020) / 1.004
4 1.236 (0.028) 1.238 (0.054) / 1.002 1.217 (0.054) / 0.985
8 1.207 (0.117) 1.198 (0.122) / 0.993 1.155 (0.138) / 0.957
16 0.758 (0.055) 1.128 (0.118) / 1.489 1.068 (0.131) / 1.409
32 0.743 (0.027) 1.153 (0.028) / 1.551 1.147 (0.021) / 1.543
36 0.708 (0.027) 1.150 (0.024) / 1.623 1.137 (0.026) / 1.605
72 0.629 (0.016) 1.112 (0.019) / 1.767 1.134 (0.019) / 1.802
108 0.610 (0.012) 1.053 (0.018) / 1.725 1.130 (0.017) / 1.853
142 0.606 (0.013) 1.008 (0.020) / 1.664 1.110 (0.023) / 1.833
Further comments are welcome and appreciated.
Alex Kogan (6):
locking/qspinlock: Rename mcs lock/unlock macros and make them more
generic
locking/qspinlock: Refactor the qspinlock slow path
locking/qspinlock: Introduce CNA into the slow path of qspinlock
locking/qspinlock: Introduce starvation avoidance into CNA
locking/qspinlock: Avoid moving certain threads between waiting queues
in CNA
locking/qspinlock: Introduce the shuffle reduction optimization into
CNA
.../admin-guide/kernel-parameters.txt | 18 +
arch/arm/include/asm/mcs_spinlock.h | 6 +-
arch/x86/Kconfig | 20 +
arch/x86/include/asm/qspinlock.h | 4 +
arch/x86/kernel/alternative.c | 4 +
include/asm-generic/mcs_spinlock.h | 4 +-
kernel/locking/mcs_spinlock.h | 20 +-
kernel/locking/qspinlock.c | 82 +++-
kernel/locking/qspinlock_cna.h | 425 ++++++++++++++++++
kernel/locking/qspinlock_paravirt.h | 2 +-
10 files changed, 562 insertions(+), 23 deletions(-)
create mode 100644 kernel/locking/qspinlock_cna.h
--
2.24.3 (Apple Git-128)
On Fri, May 14, 2021 at 04:07:40PM -0400, Alex Kogan wrote:
quoted hunk
In CNA, spinning threads are organized in two queues, a primary queue for
threads running on the same node as the current lock holder, and a
secondary queue for threads running on other nodes. After acquiring the
MCS lock and before acquiring the spinlock, the MCS lock
holder checks whether the next waiter in the primary queue (if exists) is
running on the same NUMA node. If it is not, that waiter is detached from
the main queue and moved into the tail of the secondary queue. This way,
we gradually filter the primary queue, leaving only waiters running on
the same preferred NUMA node. For more details, see
https://arxiv.org/abs/1810.05600.
Note that this variant of CNA may introduce starvation by continuously
passing the lock between waiters in the main queue. This issue will be
addressed later in the series.
Enabling CNA is controlled via a new configuration option
(NUMA_AWARE_SPINLOCKS). By default, the CNA variant is patched in at the
boot time only if we run on a multi-node machine in native environment and
the new config is enabled. (For the time being, the patching requires
CONFIG_PARAVIRT_SPINLOCKS to be enabled as well. However, this should be
resolved once static_call() is available.) This default behavior can be
overridden with the new kernel boot command-line option
"numa_spinlock=on/off" (default is "auto").
Signed-off-by: Alex Kogan <redacted>
Reviewed-by: Steve Sistare <redacted>
Reviewed-by: Waiman Long <longman@redhat.com>
---
.../admin-guide/kernel-parameters.txt | 10 +
arch/x86/Kconfig | 20 ++
arch/x86/include/asm/qspinlock.h | 4 +
arch/x86/kernel/alternative.c | 4 +
kernel/locking/mcs_spinlock.h | 2 +-
kernel/locking/qspinlock.c | 42 ++-
kernel/locking/qspinlock_cna.h | 325 ++++++++++++++++++
7 files changed, 402 insertions(+), 5 deletions(-)
create mode 100644 kernel/locking/qspinlock_cna.h
@@ -3515,6 +3515,16 @@ NUMA balancing. Allowed values are enable and disable+ numa_spinlock= [NUMA, PV_OPS] Select the NUMA-aware variant+ of spinlock. The options are:+ auto - Enable this variant if running on a multi-node+ machine in native environment.+ on - Unconditionally enable this variant.+ off - Unconditionally disable this variant.++ Not specifying this option is equivalent to+ numa_spinlock=auto.+ numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. 'node', 'default' can be specified This can be set from sysctl after boot.
@@ -1564,6 +1564,26 @@ config NUMAOtherwise,youshouldsayN.+configNUMA_AWARE_SPINLOCKS+bool"Numa-aware spinlocks"+depends onNUMA+depends onQUEUED_SPINLOCKS+depends on64BIT+# For now, we depend on PARAVIRT_SPINLOCKS to make the patching work.+# This is awkward, but hopefully would be resolved once static_call()+# is available.+depends onPARAVIRT_SPINLOCKS+defaulty+help+IntroduceNUMA(NonUniformMemoryAccess)awarenessinto+theslowpathofspinlocks.++Inthisvariantofqspinlock,thekernelwilltrytokeepthelock+onthesamenode,thusreducingthenumberofremotecachemisses,+whiletradingsomeoftheshorttermfairnessforbetterperformance.++SayNifyouwantabsolutefirstcomefirstservefairness.+configAMD_NUMAdef_boolyprompt"Old style AMD Opteron NUMA detection"
@@ -0,0 +1,325 @@+/* SPDX-License-Identifier: GPL-2.0 */+#ifndef _GEN_CNA_LOCK_SLOWPATH+#error "do not include this file"+#endif++#include<linux/topology.h>++/*+*ImplementaNUMA-awareversionofMCS(akaCNA,orcompactNUMA-awarelock).+*+*InCNA,spinningthreadsareorganizedintwoqueues,aprimaryqueuefor+*threadsrunningonthesameNUMAnodeasthecurrentlockholder,anda+*secondaryqueueforthreadsrunningonothernodes.Schematically,it+*lookslikethis:+*+*cna_node+*+----------++--------++--------++*|mcs:next|-->|mcs:next|-->...|mcs:next|-->NULL[Primaryqueue]+*|mcs:locked|-.+--------++--------++*+----------+|+*`----------------------.+*v+*+--------++--------++*|mcs:next|-->...|mcs:next|[Secondaryqueue]+*+--------++--------++*^|+*`--------------------'+*+*N.B.locked:=1ifsecondaryqueueisabsent.Otherwise,itcontainsthe+*encodedpointertothetailofthesecondaryqueue,whichisorganizedasa+*circularlist.+*+*AfteracquiringtheMCSlockandbeforeacquiringthespinlock,theMCSlock+*holdercheckswhetherthenextwaiterintheprimaryqueue(ifexists)is+*runningonthesameNUMAnode.Ifitisnot,thatwaiterisdetachedfromthe+*mainqueueandmovedintothetailofthesecondaryqueue.Thisway,we+*graduallyfiltertheprimaryqueue,leavingonlywaitersrunningonthesame+*preferredNUMAnode.+*+*Formoredetails,seehttps://arxiv.org/abs/1810.05600.+*+*Authors:AlexKogan<alex.kogan@oracle.com>+*DaveDice<dave.dice@oracle.com>+*/++structcna_node{+structmcs_spinlockmcs;+u16numa_node;+u16real_numa_node;+u32encoded_tail;/* self */+};++staticvoid__initcna_init_nodes_per_cpu(unsignedintcpu)+{+structmcs_spinlock*base=per_cpu_ptr(&qnodes[0].mcs,cpu);+intnuma_node=cpu_to_node(cpu);+inti;++for(i=0;i<MAX_NODES;i++){+structcna_node*cn=(structcna_node*)grab_mcs_node(base,i);++cn->real_numa_node=numa_node;+cn->encoded_tail=encode_tail(cpu,i);+/*+*makesure@encoded_tailisnotconfusedwithothervalid+*valuesfor@locked(0or1)+*/+WARN_ON(cn->encoded_tail<=1);+}+}++staticint__initcna_init_nodes(void)+{+unsignedintcpu;++/*+*thiswillbreakon32bitarchitectures,sowerestrict+*theuseofCNAto64bitonly(seearch/x86/Kconfig)+*/+BUILD_BUG_ON(sizeof(structcna_node)>sizeof(structqnode));+/* we store an ecoded tail word in the node's @locked field */+BUILD_BUG_ON(sizeof(u32)>sizeof(unsignedint));++for_each_possible_cpu(cpu)+cna_init_nodes_per_cpu(cpu);++return0;+}++static__always_inlinevoidcna_init_node(structmcs_spinlock*node)+{+structcna_node*cn=(structcna_node*)node;++cn->numa_node=cn->real_numa_node;+}++/*+*cna_splice_head--splicetheentiresecondaryqueueontotheheadofthe+*primaryqueue.+*+*ReturnsthenewprimaryheadnodeorNULLonfailure.+*/+staticstructmcs_spinlock*+cna_splice_head(structqspinlock*lock,u32val,+structmcs_spinlock*node,structmcs_spinlock*next)+{+structmcs_spinlock*head_2nd,*tail_2nd;+u32new;++tail_2nd=decode_tail(node->locked);+head_2nd=tail_2nd->next;++if(next){+/*+*Iftheprimaryqueueisnotempty,theprimarytaildoesn't+*needtochangeandwecansimplylinkthesecondarytailto+*theoldprimaryhead.+*/+tail_2nd->next=next;+}else{+/*+*Whentheprimaryqueueisempty,thesecondarytailbecomes+*theprimarytail.+*/++/*+*Speculativelybreakthesecondaryqueue'scircularlinksuch+*thatwhenthesecondarytailbecomestheprimarytailitall+*worksout.+*/+tail_2nd->next=NULL;++/*+*tail_2nd->next=NULL;old=xchg_tail(lock,tail);+*prev=decode_tail(old);+*try_cmpxchg_release(...);WRITE_ONCE(prev->next,node);+*+*Ifthefollowingcmpxchg()succeeds,ourstoreswillnot+*collide.+*/+new=((structcna_node*)tail_2nd)->encoded_tail|+_Q_LOCKED_VAL;+if(!atomic_try_cmpxchg_release(&lock->val,&val,new)){+/* Restore the secondary queue's circular link. */+tail_2nd->next=head_2nd;+returnNULL;+}+}++/* The primary queue head now is what was the secondary queue head. */+returnhead_2nd;+}++staticinlineboolcna_try_clear_tail(structqspinlock*lock,u32val,+structmcs_spinlock*node)+{+/*+*We'reherebecausetheprimaryqueueisempty;checkthesecondary+*queueforremotewaiters.+*/+if(node->locked>1){+structmcs_spinlock*next;++/*+*Whentherearewaitersonthesecondaryqueue,trytomove+*thembackontotheprimaryqueueandletthemrip.+*/+next=cna_splice_head(lock,val,node,NULL);+if(next){+arch_mcs_lock_handoff(&next->locked,1);+returntrue;+}++returnfalse;+}++/* Both queues are empty. Do what MCS does. */+return__try_clear_tail(lock,val,node);+}++/*+*cna_splice_next--splicethenextnodefromtheprimaryqueueonto+*thesecondaryqueue.+*/+staticvoidcna_splice_next(structmcs_spinlock*node,+structmcs_spinlock*next,+structmcs_spinlock*nnext)+{+/* remove 'next' from the main queue */+node->next=nnext;++/* stick `next` on the secondary queue tail */+if(node->locked<=1){/* if secondary queue is empty */+/* create secondary queue */+next->next=next;+}else{+/* add to the tail of the secondary queue */+structmcs_spinlock*tail_2nd=decode_tail(node->locked);+structmcs_spinlock*head_2nd=tail_2nd->next;++tail_2nd->next=next;+next->next=head_2nd;+}++node->locked=((structcna_node*)next)->encoded_tail;+}++/*+*cna_order_queue-checkwhetherthenextwaiterinthemainqueueison+*thesameNUMAnodeasthelockholder;ifnot,andithasawaiterbehind+*itinthemainqueue,movetheformerontothesecondaryqueue.+*Returns1ifthenextwaiterrunsonthesameNUMAnode;0otherwise.+*/+staticintcna_order_queue(structmcs_spinlock*node)+{+structmcs_spinlock*next=READ_ONCE(node->next);+structcna_node*cn=(structcna_node*)node;+intnuma_node,next_numa_node;++if(!next)+return0;++numa_node=cn->numa_node;+next_numa_node=((structcna_node*)next)->numa_node;++if(next_numa_node!=numa_node){+structmcs_spinlock*nnext=READ_ONCE(next->next);++if(nnext)+cna_splice_next(node,next,nnext);++return0;+}+return1;+}++#define LOCK_IS_BUSY(lock) (atomic_read(&(lock)->val) & _Q_LOCKED_PENDING_MASK)++/* Abuse the pv_wait_head_or_lock() hook to get some work done */+static__always_inlineu32cna_wait_head_or_lock(structqspinlock*lock,+structmcs_spinlock*node)+{+/*+*Tryandputthetimeotherwisespentspinwaitingon+*_Q_LOCKED_PENDING_MASKtousebysortingourlists.+*/+while(LOCK_IS_BUSY(lock)&&!cna_order_queue(node))+cpu_relax();++return0;/* we lied; we didn't wait, go do so now */+}++staticinlinevoidcna_lock_handoff(structmcs_spinlock*node,+structmcs_spinlock*next)+{+u32val=1;++if(node->locked>1){+structcna_node*cn=(structcna_node*)node;++val=node->locked;/* preseve secondary queue */++/*+*Wehavealocalwaiter,eitherrealorfakeone;+*reload@nextincaseitwaschangedbycna_order_queue().+*/+next=node->next;++/*+*PassoverNUMAnodeidofprimaryqueue,tomaintainthe+*preferenceevenifthenextwaiterisonadifferentnode.+*/+((structcna_node*)next)->numa_node=cn->numa_node;+}++arch_mcs_lock_handoff(&next->locked,val);+}++/*+*Constant(boot-paramconfigurable)flagselectingtheNUMA-awarevariant+*ofspinlock.Possiblevalues:-1(off)/0(auto,default)/1(on).+*/+staticintnuma_spinlock_flag;++staticint__initnuma_spinlock_setup(char*str)+{+if(!strcmp(str,"auto")){+numa_spinlock_flag=0;+return1;+}elseif(!strcmp(str,"on")){+numa_spinlock_flag=1;+return1;+}elseif(!strcmp(str,"off")){+numa_spinlock_flag=-1;+return1;+}++return0;+}+__setup("numa_spinlock=",numa_spinlock_setup);++void__cna_queued_spin_lock_slowpath(structqspinlock*lock,u32val);++/*+*SwitchtotheNUMA-friendlyslowpathforspinlockswhenwehave+*multipleNUMAnodesinnativeenvironment,unlesstheuserhas+*overriddenthisdefaultbehaviorbysettingthenuma_spinlockflag.+*/+void__initcna_configure_spin_lock_slowpath(void)+{++if(numa_spinlock_flag<0)+return;++if(numa_spinlock_flag==0&&(nr_node_ids<2||+pv_ops.lock.queued_spin_lock_slowpath!=+native_queued_spin_lock_slowpath))+return;++cna_init_nodes();++pv_ops.lock.queued_spin_lock_slowpath=__cna_queued_spin_lock_slowpath;
The pv_ops is belongs to x86 custom frame work, and it prevent other
architectures connect to the CNA spinlock.
I'm working on riscv qspinlock on sg2042 64 cores 2/4 NUMA nodes
platforms. Here are the patches about riscv CNA qspinlock:
https://lore.kernel.org/linux-riscv/20230802164701.192791-19-guoren@kernel.org/
What's the next plan for this patch series? I think the two-queue design
has satisfied most platforms with two NUMA nodes.
From: Peter Zijlstra <peterz@infradead.org> Date: 2023-08-03 08:50:51
On Wed, Aug 02, 2023 at 07:14:05PM -0400, Guo Ren wrote:
The pv_ops is belongs to x86 custom frame work, and it prevent other
architectures connect to the CNA spinlock.
static_call() exists as a arch neutral variant of this.
I'm working on riscv qspinlock on sg2042 64 cores 2/4 NUMA nodes
platforms. Here are the patches about riscv CNA qspinlock:
https://lore.kernel.org/linux-riscv/20230802164701.192791-19-guoren@kernel.org/
What's the next plan for this patch series? I think the two-queue design
has satisfied most platforms with two NUMA nodes.
What has been your reason for working on CNA? What lock has been so
contended you need this?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, Aug 3, 2023 at 4:50 PM Peter Zijlstra [off-list ref] wrote:
On Wed, Aug 02, 2023 at 07:14:05PM -0400, Guo Ren wrote:
quoted
The pv_ops is belongs to x86 custom frame work, and it prevent other
architectures connect to the CNA spinlock.
static_call() exists as a arch neutral variant of this.
Emm... we have used static_call() in the riscv queued_spin_lock_:
https://lore.kernel.org/all/20230802164701.192791-20-guoren@kernel.org/
But we met a compile problem:
GEN .vmlinux.objs
MODPOST Module.symvers
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [arch/riscv/kvm/kvm.ko]
undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[kernel/locking/locktorture.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [mm/z3fold.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/nfs_common/grace.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v1.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v2.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/quota/quota_tree.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fuse/virtiofs.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/dlm/dlm.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fscache/fscache.ko]
undefined!
WARNING: modpost: suppressed 839 unresolved symbol warnings because
there were too many)
/home/guoren/source/kernel/linux/scripts/Makefile.modpost:144: recipe
for target 'Module.symvers' failed
Our solution is:
EXPORT_SYMBOL(__SCK__pv_queued_spin_unlock);
What do you think about it?
quoted
I'm working on riscv qspinlock on sg2042 64 cores 2/4 NUMA nodes
platforms. Here are the patches about riscv CNA qspinlock:
https://lore.kernel.org/linux-riscv/20230802164701.192791-19-guoren@kernel.org/
What's the next plan for this patch series? I think the two-queue design
has satisfied most platforms with two NUMA nodes.
What has been your reason for working on CNA? What lock has been so
contended you need this?
Yeah, I think I saw that land in the INBOX, just haven't had time to
look at it.
But we met a compile problem:
GEN .vmlinux.objs
MODPOST Module.symvers
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [arch/riscv/kvm/kvm.ko]
undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[kernel/locking/locktorture.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [mm/z3fold.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/nfs_common/grace.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v1.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v2.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/quota/quota_tree.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fuse/virtiofs.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/dlm/dlm.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fscache/fscache.ko]
undefined!
WARNING: modpost: suppressed 839 unresolved symbol warnings because
there were too many)
/home/guoren/source/kernel/linux/scripts/Makefile.modpost:144: recipe
for target 'Module.symvers' failed
Our solution is:
EXPORT_SYMBOL(__SCK__pv_queued_spin_unlock);
What do you think about it?
Could be you're not using static_call_mod() to go with
EXPORT_STATIC_CALL_TRAMP()
quoted
quoted
I'm working on riscv qspinlock on sg2042 64 cores 2/4 NUMA nodes
platforms. Here are the patches about riscv CNA qspinlock:
https://lore.kernel.org/linux-riscv/20230802164701.192791-19-guoren@kernel.org/
What's the next plan for this patch series? I think the two-queue design
has satisfied most platforms with two NUMA nodes.
What has been your reason for working on CNA? What lock has been so
contended you need this?
CNA should only show a benefit when there is strong inter-node
contention, and in that case it is typically best to fix the kernel side
locking.
Hence the question as to what lock prompted you to look at this.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Yeah, I think I saw that land in the INBOX, just haven't had time to
look at it.
quoted
But we met a compile problem:
GEN .vmlinux.objs
MODPOST Module.symvers
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [arch/riscv/kvm/kvm.ko]
undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[kernel/locking/locktorture.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [mm/z3fold.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/nfs_common/grace.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v1.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v2.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/quota/quota_tree.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fuse/virtiofs.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/dlm/dlm.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fscache/fscache.ko]
undefined!
WARNING: modpost: suppressed 839 unresolved symbol warnings because
there were too many)
/home/guoren/source/kernel/linux/scripts/Makefile.modpost:144: recipe
for target 'Module.symvers' failed
Our solution is:
EXPORT_SYMBOL(__SCK__pv_queued_spin_unlock);
What do you think about it?
Could be you're not using static_call_mod() to go with
EXPORT_STATIC_CALL_TRAMP()
Thx, that's what I want.
quoted
quoted
quoted
I'm working on riscv qspinlock on sg2042 64 cores 2/4 NUMA nodes
platforms. Here are the patches about riscv CNA qspinlock:
https://lore.kernel.org/linux-riscv/20230802164701.192791-19-guoren@kernel.org/
What's the next plan for this patch series? I think the two-queue design
has satisfied most platforms with two NUMA nodes.
What has been your reason for working on CNA? What lock has been so
contended you need this?
CNA should only show a benefit when there is strong inter-node
contention, and in that case it is typically best to fix the kernel side
locking.
Hence the question as to what lock prompted you to look at this.
I met the long lock queue situation when the hardware gave an overly
aggressive store queue merge buffer delay mechanism. See:
https://lore.kernel.org/linux-riscv/20230802164701.192791-8-guoren@kernel.org/
This also let me consider improving the efficiency of the long lock
queue release. For example, if the queue is like this:
(Node0 cpu0) -> (Node1 cpu64) -> (Node0 cpu1) -> (Node1 cpu65) ->
(Node0 cpu2) -> (Node1 cpu66) -> ...
Then every mcs_unlock would cause a cross-NUMA transaction. But if we
could make the queue like this:
(Node0 cpu0) -> (Node0 cpu1) -> (Node0 cpu2) -> (Node1 cpu65) ->
(Node1 cpu66) -> (Node1 cpu64) -> ...
Only one cross-NUMA transaction is needed. Although it would cause
starvation problems, qspinlock.numa_spinlock_threshold_ns could give a
basic guarantee.
--
Best Regards
Guo Ren
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Yeah, I think I saw that land in the INBOX, just haven't had time to
look at it.
quoted
But we met a compile problem:
GEN .vmlinux.objs
MODPOST Module.symvers
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [arch/riscv/kvm/kvm.ko]
undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[kernel/locking/locktorture.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [mm/z3fold.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/nfs_common/grace.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v1.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/quota/quota_v2.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock"
[fs/quota/quota_tree.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fuse/virtiofs.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/dlm/dlm.ko] undefined!
ERROR: modpost: "__SCK__pv_queued_spin_unlock" [fs/fscache/fscache.ko]
undefined!
WARNING: modpost: suppressed 839 unresolved symbol warnings because
there were too many)
/home/guoren/source/kernel/linux/scripts/Makefile.modpost:144: recipe
for target 'Module.symvers' failed
Our solution is:
EXPORT_SYMBOL(__SCK__pv_queued_spin_unlock);
What do you think about it?
Could be you're not using static_call_mod() to go with
EXPORT_STATIC_CALL_TRAMP()
Thx, that's what I want.
quoted
quoted
quoted
quoted
I'm working on riscv qspinlock on sg2042 64 cores 2/4 NUMA nodes
platforms. Here are the patches about riscv CNA qspinlock:
https://lore.kernel.org/linux-riscv/20230802164701.192791-19-guoren@kernel.org/
What's the next plan for this patch series? I think the two-queue design
has satisfied most platforms with two NUMA nodes.
What has been your reason for working on CNA? What lock has been so
contended you need this?
CNA should only show a benefit when there is strong inter-node
contention, and in that case it is typically best to fix the kernel side
locking.
Hence the question as to what lock prompted you to look at this.
I met the long lock queue situation when the hardware gave an overly
aggressive store queue merge buffer delay mechanism. See:
https://lore.kernel.org/linux-riscv/20230802164701.192791-8-guoren@kernel.org/
This also let me consider improving the efficiency of the long lock
queue release. For example, if the queue is like this:
(Node0 cpu0) -> (Node1 cpu64) -> (Node0 cpu1) -> (Node1 cpu65) ->
(Node0 cpu2) -> (Node1 cpu66) -> ...
Then every mcs_unlock would cause a cross-NUMA transaction. But if we
could make the queue like this:
(Node0 cpu0) -> (Node0 cpu1) -> (Node0 cpu2) -> (Node1 cpu65) ->
(Node1 cpu66) -> (Node1 cpu64) -> ...
Only one cross-NUMA transaction is needed. Although it would cause
starvation problems, qspinlock.numa_spinlock_threshold_ns could give a
basic guarantee.
I thought it was a tradeoff for the balance between fairness and efficiency.
@@ -3515,6 +3515,16 @@ NUMA balancing. Allowed values are enable and disable+ numa_spinlock= [NUMA, PV_OPS] Select the NUMA-aware variant+ of spinlock. The options are:+ auto - Enable this variant if running on a multi-node+ machine in native environment.+ on - Unconditionally enable this variant.
Is there any reason why the user would explicitly pass the on option
when the auto thing already does the multi-node check? Perhaps strange
numa topologies? Otherwise I would say it's not needed and the fewer
options we give the user for low level locking the better.
quoted
+ off - Unconditionally disable this variant.
+
+ Not specifying this option is equivalent to
+ numa_spinlock=auto.
+
numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
'node', 'default' can be specified
This can be set from sysctl after boot.
@@ -1564,6 +1564,26 @@ config NUMAOtherwise,youshouldsayN.+configNUMA_AWARE_SPINLOCKS+bool"Numa-aware spinlocks"+depends onNUMA+depends onQUEUED_SPINLOCKS+depends on64BIT+# For now, we depend on PARAVIRT_SPINLOCKS to make the patching work.+# This is awkward, but hopefully would be resolved once static_call()+# is available.+depends onPARAVIRT_SPINLOCKS
We now have static_call() - see 9183c3f9ed7.
quoted
+ default y
+ help
+ Introduce NUMA (Non Uniform Memory Access) awareness into
+ the slow path of spinlocks.
+
+ In this variant of qspinlock, the kernel will try to keep the lock
+ on the same node, thus reducing the number of remote cache misses,
+ while trading some of the short term fairness for better performance.
+
+ Say N if you want absolute first come first serve fairness.
This would also need a depends on !PREEMPT_RT, no? Raw spinlocks really want
the determinism.
I hope we shouldn't force disable it in the Kconfig. Could we put this
idea in numa_spinlock=auto?
From: Peter Zijlstra <peterz@infradead.org> Date: 2023-08-04 08:26:27
On Fri, Aug 04, 2023 at 09:33:48AM +0800, Guo Ren wrote:
On Thu, Aug 3, 2023 at 7:57 PM Peter Zijlstra [off-list ref] wrote:
quoted
CNA should only show a benefit when there is strong inter-node
contention, and in that case it is typically best to fix the kernel side
locking.
Hence the question as to what lock prompted you to look at this.
*groan*, so you're using it to work around 'broken' hardware :-(
Wouldn't that hardware have horrifically bad lock throughput anyway?
Everybody would end up waiting on that store buffer delay.
This also let me consider improving the efficiency of the long lock
queue release. For example, if the queue is like this:
(Node0 cpu0) -> (Node1 cpu64) -> (Node0 cpu1) -> (Node1 cpu65) ->
(Node0 cpu2) -> (Node1 cpu66) -> ...
Then every mcs_unlock would cause a cross-NUMA transaction. But if we
could make the queue like this:
See, this is where the ARM64 WFE would come in handy; I don't suppose
RISC-V has anything like that?
Also, by the time you have 6 waiters, I'd say the lock is terribly
contended and you should look at improving the lockinh scheme.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Aug 4, 2023 at 4:26 PM Peter Zijlstra [off-list ref] wrote:
On Fri, Aug 04, 2023 at 09:33:48AM +0800, Guo Ren wrote:
quoted
On Thu, Aug 3, 2023 at 7:57 PM Peter Zijlstra [off-list ref] wrote:
quoted
quoted
CNA should only show a benefit when there is strong inter-node
contention, and in that case it is typically best to fix the kernel side
locking.
Hence the question as to what lock prompted you to look at this.
*groan*, so you're using it to work around 'broken' hardware :-(
Yes, the hardware needs to be improved, and it couldn't depend on
WRITE_ONCE() hack. But from another view, if we tell the hardware this
is a WRITE_ONCE(), this store instruction should be observed by
sibling cores immediately, then the hardware could optimize the
behavior in the store queue. (All modern processors have a store queue
beyond the cache, and there is latency between the store queue and the
cache.) So:
How about adding an instruction of "st.aqrl" for WRITE_ONCE()? Which
makes the WRITE_ONCE() become the RCsc synchronization point.
Wouldn't that hardware have horrifically bad lock throughput anyway?
Everybody would end up waiting on that store buffer delay.
This problem is only found in the lock torture case, and only one
entry left in the store buffer would cause the problem. We are now
widely stress testing userspace parallel applications to find a second
case. Yes, we must be careful to treat this.
quoted
This also let me consider improving the efficiency of the long lock
queue release. For example, if the queue is like this:
c -> c -> (Node0 cpu1) -> (Node1 cpu65) ->
(Node0 cpu2) -> (Node1 cpu66) -> ...
Then every mcs_unlock would cause a cross-NUMA c. But if we
could make the queue like this:
See, this is where the ARM64 WFE would come in handy; I don't suppose
RISC-V has anything like that?
Em... arm64 smp_cond_load only could save power consumption or release
the pipeline resources of an SMT processor. When (Node1 cpu64) is in
the WFE state, it still needs (Node0 cpu1) to write the value to give
a cross-NUMA signal. So I didn't see what WFE related to reducing
cross-Numa transactions, or I missed something. Sorry
Also, by the time you have 6 waiters, I'd say the lock is terribly
contended and you should look at improving the lockinh scheme.
From: Peter Zijlstra <peterz@infradead.org> Date: 2023-08-04 18:24:29
On Fri, Aug 04, 2023 at 10:17:35AM -0400, Guo Ren wrote:
quoted
See, this is where the ARM64 WFE would come in handy; I don't suppose
RISC-V has anything like that?
Em... arm64 smp_cond_load only could save power consumption or release
the pipeline resources of an SMT processor. When (Node1 cpu64) is in
the WFE state, it still needs (Node0 cpu1) to write the value to give
a cross-NUMA signal. So I didn't see what WFE related to reducing
cross-Numa transactions, or I missed something. Sorry
The benefit is that WFE significantly reduces the memory traffic. Since
it 'suspends' the core and waits for a write-notification instead of
busy polling the memory location you get a ton less loads.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Aug 4, 2023 at 2:24 PM Peter Zijlstra [off-list ref] wrote:
On Fri, Aug 04, 2023 at 10:17:35AM -0400, Guo Ren wrote:
quoted
quoted
See, this is where the ARM64 WFE would come in handy; I don't suppose
RISC-V has anything like that?
Em... arm64 smp_cond_load only could save power consumption or release
the pipeline resources of an SMT processor. When (Node1 cpu64) is in
the WFE state, it still needs (Node0 cpu1) to write the value to give
a cross-NUMA signal. So I didn't see what WFE related to reducing
cross-Numa transactions, or I missed something. Sorry
The benefit is that WFE significantly reduces the memory traffic. Since
it 'suspends' the core and waits for a write-notification instead of
busy polling the memory location you get a ton less loads.
Em... I had a different observation: When a long lock queue appeared
by a store buffer delay problem in the lock torture test, we observed
all interconnects get into a quiet state, and there was no more memory
traffic. All the cores are loop-loading "different" cacheline from
their L1 cache, caused by queued_spinlock. So I don't see any memory
traffics on the bus.
For the LL + WFE, AFAIK, LL is a load instruction that would grab the
cacheline from the bus into the L1-cache and set the reservation set
(arm may call it exclusive-monitor). If any cacheline invalidation
requests (readunique/cleanunique/...) come in, WFE would retire, and
the reservation set would be cleared. So from a cacheline perspective,
there is no difference between "LL+WFE" and "looping loads."
Let's see two scenarios of LL+WFE, multi-cores, and muti-threadings of one core:
- In the multi-cores case, WFE didn't give any more benefits than the
loop loading from my perspective. Because the only thing WFE could do
is to "suspend core" (I borrowed your word here), but it can't be deep
sleep because the response from WFE is the most prior thing. As you
said, we should prevent "terribly contended" situations, so WFE must
keep fast reactions in the pipeline, not deep sleep. That's WFI stuff.
And loop loading also could reduce power consumption through the
proper micro-arch design: When the pipeline gets into a loop loading
state, the loop buffer mechanism start, no instructions fetch happens,
the frontend component can suspend for a while, and the only working
components are "loop buffer" and "LSU load path." Other components
could suspend for a while. So loop loading is not as terrible as you
thought.
- In the multi-threading of one core case, introducing an ISA
instruction (WFE) to solve the loop loading problem is worthwhile
because the thread could release the resource of the processor's pipe
line.