Towards scalable RDMA locking on a NIC

Transcription

1 TORSTEN HOEFLER spcl.inf.ethz.ch Towards scalable RDMA locking on a NIC with support of Patrick Schmid, Maciej Besta, Salvatore di SPCL presented at HP Labs, Palo Alto, CA, USA

2 NEED FOR EFFICIENT LARGE-SCALE SYNCHRONIZATION spcl.inf.ethz.ch

3 LOCKS An example structure Proc p Proc q Inuitive semantics Various performance penalties

4 LOCKS: CHALLENGES P1 P2 P3 P4

5 LOCKS: CHALLENGES We need intra- and inter-node topologyawareness We need to cover arbitrary topologies P P P P P P P P P P P P

6 LOCKS: CHALLENGES We need to distinguish Writer between Reader readers Reader and writers Reader Reader Reader Reader Writer Reader Reader We need flexible performance for both types of processes [1] V. Venkataramani et al. Tao: How facebook serves the social graph. SIGMOD 12.

7 What will we use in the design? spcl.inf.ethz.ch

8 WHAT WE WILL USE MCS Locks Proc Proc Proc Proc Cannot enter Cannot enter Cannot enter Can enter Next proc Next proc... Next proc Next proc Pointer to the queue tail

9 WHAT WE WILL USE Reader-Writer Locks W R R R... R

10 How to manage the design complexity? How to ensure tunable performance? What mechanism to use for efficient implementation?

11 REMOTE MEMORY ACCESS (RMA) PROGRAMMING Process p Process q Memory A A put A Memory B get B flush B Cray BlueWaters

12 REMOTE MEMORY ACCESS PROGRAMMING Implemented in hardware in NICs in the majority of HPC networks support RDMA

13 How to manage the design complexity? How to ensure tunable performance? What mechanism to use for efficient implementation?

14 How to manage the design complexity? Each element has its own distributed MCS queue (DQ) of writers R1 R2... R9 W3 W8 Readers and writers synchronize with a distributed counter (DC) Modular design W1 W3 W5 W8 MCS queues form a distributed tree (DT) R4 R2 R1 R5 R3 R8 R6 R7 R9 W1 W2 W3 W4 W5 W6 W7 W8

15 R1 R2... How to ensure tunable performance? R9 W3 W8 Each DQ: fairness vs throughput of writers DC: a parameter for the latency of readers vs writers A tradeoff parameter for every structure W1 W3 W5 W8 DT: a parameter for the throughput of readers vs writers R4 R2 R1 R5 R3 R8 R6 R7 R9 W1 W2 W3 W4 W5 W6 W7 W8

16 DISTRIBUTED MCS QUEUES (DQS) Throughput vs Fairness Larger T L,i : more throughput at level i. Smaller T L,i : more fairness at level i. T L,3 W3 W8 Each DQ: The maximum number of lock passings within a DQ at level i, before it is passed to another DQ at i. T L,i T L,2 T L,2 W1 W3 W5 W8 T L,1 T L,1 T L,1 T L,1 W1 W2 W3 W4 W5 W6 W7 W8

17 DISTRIBUTED TREE OF QUEUES (DT) Throughput of readers vs writers R1 R2... R9 T L,3 W3 W8 DT: The maximum number of consecutive lock passings within readers ( ). T R T L,2 T L,2 W1 W3 W5 W8 T L,1 T L,1 T L,1 T L,1 W1 W2 W3 W4 W5 W6 W7 W8

18 DISTRIBUTED COUNTER (DC) Latency of readers vs writers DC: every kth compute node hosts a partial counter, all of which constitute the DC. k = T DC A writer holds the lock Readers that arrived at the CS b x y T DC = 1 T DC = 2 Readers that left the CS R R4 R R2 R3 R8 R6 R7 R

19 Locality vs fairness (for writers) spcl.inf.ethz.ch THE SPACE OF DESIGNS T L,i Design B Design A Higher throughput of writers vs readers T R T DC

20 LOCK ACQUIRE BY READERS A lightweight acquire protocol for readers: only one atomic fetch-and-add (FAA) operation FAA R FAA R4 A writer holds the lock Readers that arrived at the CS b x y Readers that left the CS FAA R2 FAA R3

21 LOCK ACQUIRE BY WRITERS R1 R2... R9 W9 W3 W8 Acquire the main MCS lock Acquire the main lock Acquire MCS Acquire MCS W9 W1 W3 W5 W W9 W1 W2 W3 W4 W5 W6 W7 W8

22 EVALUATION CSCS Piz Daint (Cray XC30) 5272 compute nodes 8 cores per node 169TB memory

23 EVALUATION CONSIDERED BENCHMARKS Throughput benchmarks: The latency benchmark Empty-critical-section Single-operation Wait-after-release Workload-critical-section DHT Distributed hashtable evaluation

24 EVALUATION DISTRIBUTED COUNTER ANALYSIS Throughput, 2% writers Single-operation benchmark

25 EVALUATION READER THRESHOLD ANALYSIS Throughput, 0.2% writers, Empty-critical-section benchmark

26 EVALUATION COMPARISON TO THE STATE-OF-THE-ART [1] R. Gerstenberger et al. Enabling Highly-scalable Remote Memory Access Programming with MPI-3 One Sided. ACM/IEEE Supercomputing 2013.

27 EVALUATION COMPARISON TO THE STATE-OF-THE-ART Throughput, single-operation benchmark [1] R. Gerstenberger et al. Enabling Highly-scalable Remote Memory Access Programming with MPI-3 One Sided. ACM/IEEE Supercomputing 2013.

28 EVALUATION DISTRIBUTED HASHTABLE 20% writers 10% writers [1] R. Gerstenberger et al. Enabling Highly-scalable Remote Memory Access Programming with MPI-3 One Sided. ACM/IEEE Supercomputing 2013.

29 EVALUATION DISTRIBUTED HASHTABLE 2% of writers 0% of writers [1] R. Gerstenberger et al. Enabling Highly-scalable Remote Memory Access Programming with MPI-3 One Sided. ACM/IEEE Supercomputing 2013.

30 OTHER ANALYSES spcl.inf.ethz.ch

31 But why stop at RDMA -- A brief history How to program We need an QsNet? abstraction! Lossy Networks Ethernet Lossless Networks RDMA How to offload in libfabric? How to offload in Portals 4? Device Programming Offload 1980 s 2000 s 2020 s 35

32 Communications (non-blocking) Computations Dependencies recv comp EXPRESS L0: recv a from P1; L1: b = compute f(buff, a); L2: send b to P1; L0 and CPU-> L1 L1 -> L2 OFFLOAD send CPU Offload Engine 36

33 Performance Model P0 CPU OE o (s-1)g (s-1)g m o time P1 OE CP U (s-1)g o m o (s-1)g P0{ L0: recv m1 from P1; L1: send m2 to P1; } P1{ L0: recv m1 from P1; L1: send m2 to P1; L0 -> L1 } [1] A. Alexandrov et al. "LogGP: incorporating long messages into the LogP model one step closer towards a realistic model for parallel computation., Proceedings of the seventh annual ACM symposium on Parallel algorithms and architectures. ACM,

34 Fully Offloaded Collectives Collective communication: A communication that involves a group of processes Non-blocking collective: Once initiated the operation may progress independently of any computation or other communication at participating processes P0 P1 P2 P3 P4 P5 P6 P7 38

35 Fully Offloaded Collectives Collective communication: A communication that involves a group of processes Non-blocking collective: Once initiated the operation may progress independently of any computation or other communication at participating processes P0 S Fully Offloading: P1 P2 P3 1. No synchronization is required in order to start the collective operation 2. Once a collective operation is started, no further CPU intervention R is required in order to progress or complete it. P4 P5 P6 C C R P7 39

36 A Case Study: Portals 4 Based on the one-sided communication model Matching/Non-Matching semantics can be adopted M D M D M D M D NI Interconnection Network NI Portals Table ME ME ME ME ME Discard Initiator Target Priority List Overflow List [2] The Portal Network Programming Interface 40

37 A Case Study: Portals 4 Communication primitives Put/Get operations are natively supported by Portals 4 One-sided + matching semantic Atomic operations Operands are the data specified by the MD at the initiator and by the ME at the target Available operators: min, max, sum, prod, swap, and, or, Counters Associated with MDs or MEs x Count specific ct events (e.g., operation ct completion) y Triggered operations Put/Get/Atomic associated with a counter x x y y Executed when the associated counter reaches the specified threshold ct z ct 41

38 FFlib: An Example Proof of concept library implemented on top of Portals 4 ff_schedule_h sched = ff_schedule_create( ); ff_op_h r1 = ff_op_create_recv(tmp + blocksize, blocksize, child1, tag); ff_op_h r2 = ff_op_create_recv(tmp + 2*blocksize, blocksize, child2, tag); ff_op_h c1 = ff_op_create_computation(rbuff, blocksize, tmp + blocksize, blocksize, operator, datatype, tag) ff_op_h c2 = ff_op_create_computation(rbuff, blocksize, tmp + 2*blocksize, blocksize, operator, datatype, tag) ff_op_h s = ff_op_create_send(rbuff, blocksize, parent, tag) ff_op_hb(r1, c1) ff_op_hb(r2, c2) ff_op_hb(c1, s) ff_op_hb(c2, s) ff_schedule_add(sched, r1) ff_schedule_add(sched, r2) ff_schedule_add(sched, c1) ff_schedule_add(sched, c2) ff_schedule_add(sched, s) C R S C R 42

39 Experimental Results Target machine: Curie 5,040 nodes 2 eight-core Intel Sandy Bridge processors Full fat-tree Infiniband QDR OMPI/P4: Open MPI Portals 4 RL FFLIB: proof of concept library More about FFLIB at : 43

40 Experimental Results: Latency/Overhead Broadcast Allreduce Target machine: Curie 5,040 nodes 2 eight-core Intel Sandy Bridge processors Full fat-tree Infiniband QDR OMPI/P4: Open MPI Portals 4 RL FFLIB: proof of concept library More about FFLIB at : 44

41 Experimental Results: Latency/Overhead Scatter Allgather Target machine: Curie 5,040 nodes 2 eight-core Intel Sandy Bridge processors Full fat-tree Infiniband QDR OMPI/P4: Open MPI Portals 4 RL FFLIB: proof of concept library More about FFLIB at : 45

42 PGMRES 3DFFT spcl.inf.ethz.ch Experimental Results: Micro-Benchmarks P=64 P=128 P=256 Target machine: Curie 5,040 nodes 2 eight-core Intel Sandy Bridge processors Full fat-tree Infiniband QDR OMPI/P4: Open MPI Portals 4 RL FFLIB: proof of concept library More about FFLIB at : 46

43 Simulations Why? To study offloaded collectives at large scale How? Extending the LogGOPSim to simulate Portals 4 functionalities Broadcast Allreduce L o g G m P4-SW 5μs 6μs 6μs 0.4ns 0.9ns P4-HW 2.7μs 1.2μs 0.5μs 0.4ns 0.3ns [4] [3] T. Hoefler, T. Schneider, A. Lumsdaine. LogGOPSim - Simulating Large-Scale Applications in the LogGOPS Model, In Proceedings of the 19th ACM International Symposium on High Performance Distributed Computing (HPDC '10). ACM, [4] Underwood et al., "Enabling Flexible Collective Communication Offload with Triggered Operations, IEEE 19th Annual Symposium on High Performance Interconnects (HOTI 11). IEEE, 2011.

44 Abstract Machine Model Offloading Collectives Solo Collectives Mapping to Portals 4 FFlib Result s

45 CONCLUSIONS Modular distributed RMA lock, correctness with SPIN Parameter-based design, feasible with various RMA libs/languages Thank you for your attention Improves latency and throughput over state-of-the-art Enables high-performance distributed hashtabled