lock free rw concurrency in hash library - home - dpdk

18
x Lock Free RW Concurrency in hash library HONNAPPA NAGARAHALLI ARM

Upload: others

Post on 05-Jun-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Lock Free RW Concurrency in hash library - Home - DPDK

x

Lock Free RW Concurrency in hash library

HONNAPPA NAGARAHALLI ARM

Page 2: Lock Free RW Concurrency in hash library - Home - DPDK

2

Agenda

•  Current Issues

•  Ingredients for lock free algorithms

•  Design for lock free RW concurrency in rte_hash

•  Reclaiming Memory

•  Plan for upstreaming

Page 3: Lock Free RW Concurrency in hash library - Home - DPDK

3

Current Issues

•  Preempted writer will block the readers

•  Problem applies for platforms with HTM when it falls back to traditional locks static inline void rte_rwlock_write_lock_tm(rte_rwlock_t *rwl)

{

if (likely(rte_try_tm(&rwl->cnt)))

return;

rte_rwlock_write_lock(rwl); == fallback to traditional lock }

•  Application uses the key store index to reference its data •  Index should not be freed till the application has stopped using it

Page 4: Lock Free RW Concurrency in hash library - Home - DPDK

4

Current Issues

•  Performance of lookups in the presence of writers

0 500 1000 1500 2000 2500 3000

2

4

6

8

10

12

Lookupperformancewithandwithoutadd

Lookup Lookupwithadd

Page 5: Lock Free RW Concurrency in hash library - Home - DPDK

5

Ingredients for lock free algorithms

•  Atomic operations – sizes matter, look for wider support

•  Memory ordering operations – Memory barriers or C11 atomics

•  Orderings by themselves are not enough. Need to identify the ‘payload’ and

‘guard’

•  Payload – the data being propagated from writer to reader, accesses are not

required to be atomic

•  Guard – Protects access to the payload, accesses need to be atomic

•  Synchronizes with relationship between writer and reader

Page 6: Lock Free RW Concurrency in hash library - Home - DPDK

6

Ingredients for lock free algorithms

•  Data structure specific challenges

•  Re-claiming memory

•  Readers continue to reference an entry in the data structure even the after

delete

•  Memory cannot be ‘freed’ immediately after ‘delete’

•  Delete – Remove the reference to memory/entry

•  Free – Returning the memory/entries to free pool

•  Mechanisms are required to identify when to ‘free’ the entry/memory

Page 7: Lock Free RW Concurrency in hash library - Home - DPDK

7

Design

•  Atomic Operations – relying on 32b operations

•  Memory orderings – working with C11 atomic functions •  Payload 1 – key (stored in key store) •  Guard 1 – pdata (stored in key store) •  Payload 2 - current signature and alternate signature (stored in bucket entry) •  Guard 2 – Index to {key, pdata} entry in the key store (stored in bucket entry)

Page 8: Lock Free RW Concurrency in hash library - Home - DPDK

8

Design – Ordering Mem Operations – Hash Add/Lookup

Writer Reader KS BE Key, Data (K, D)

Sig, Key-Index (S, I)

Store K

a

Store - Rel I

BLoad - Acq I

C

K Load d

Store S

b

Load S c

Store - Rel D

A

D Load - Acq D

Non-Atomic

Atomic

A Synchronizes with D

B Synchronizes with C

Notice that A and

D need not be atomic

operations

Page 9: Lock Free RW Concurrency in hash library - Home - DPDK

9

Design – Ordering Mem Operations – Hash Update/Lookup

Writer Reader KS BE Key, Data

(K, D) Sig, Key-Index

(S, I)

Load - Acq I B

K Load c

Load S b

Store - Rel D

A

D Load - Acq C

Non-Atomic

Atomic

A Synchronizes with C

Load - Acq I

K Load

Load S

D Load - Acq

For hash update ‘Key Index’ can’t be used as the guard.

This forces us to have 2 sets of payloads and guards.

If hash update is changed to allocate a new key entry from key store, memory orderings can be simplified.

Page 10: Lock Free RW Concurrency in hash library - Home - DPDK

10

Design – Data Structure Specific Challenge

Writer Reader P S

Lookup Fails

Move to primary

Entry is in secondary bucket

•  Hash add can move entries to their alternate positions

•  Due to concurrent adds, reader might not find the entry even though it is present

Entry is moved from secondary bucket Lookup Fails

!

Entry is NOT in secondary bucket

Primary Bucket

Secondary Bucket

Page 11: Lock Free RW Concurrency in hash library - Home - DPDK

11

Design – Data Structure Specific Challenge

Writer Reader P S

Lookup Fails

Move to primary

Entry is in secondary bucket

•  Solution uses a global counter

•  Counter indicates to the reader that the table has changed

Entry is moved from secondary bucket Lookup Fails

Entry is NOT in secondary bucket

Primary Bucket

Secondary Bucket C Global

Counter

Increment

Read

Read Counter changed, repeat the lookup

•  Entry present but not moving – entry is found immediately

•  Entry present but moving – reader has to chase it

•  Entry not present – Repeats till the move stops –

Can be improved by using bucket counter

Page 12: Lock Free RW Concurrency in hash library - Home - DPDK

12

Re-claiming Memory – TQS

•  Thread Quiescent State (TQS) - Any place in the code where the thread does not hold a reference to shared memory

D1 D2 D3

D1 D2 D3

D1 D2 D3

while(1)loop

D1 D2 D3

ReaderThread1

T2

T3

T4

Time

Critical Sections – reference shared memory in D1, D2 and D3 data structures

Quiescent states – do not reference any shared memory.

CriticalSection

Quiescent states for D1

Page 13: Lock Free RW Concurrency in hash library - Home - DPDK

13

D1 D2 D3ReaderThread1

D1 D2 D3T2

D1 D2 D3T3

D1 D2 D3T4

Re-claiming Memory – Delete/Free

Free the memory after every thread has gone through at least 1 quiescent state

Free

Won’t reference the ‘deleted’ memory

Remove the reference to shared

memory

Can’t free memory during this period as threads are still referencing it

DeleteDelete an entry

from data structure D2

Page 14: Lock Free RW Concurrency in hash library - Home - DPDK

14

Re-claiming Memory – rte_tqs library

•  rte_tqs library

•  Provides the ability to check if a set of reader threads have entered at least 1

quiescent state

•  Goals

•  Provide flexibility to check the quiescent state

Ø  Single data structure, a group of data structures or any application defined granularity

•  Ability to check the quiescent state of a given set/all of readers

•  Ability to check quiescent state synchronously

•  Ability to check quiescent state at a later point

Page 15: Lock Free RW Concurrency in hash library - Home - DPDK

15

Re-claiming Memory – rte_tqs library

•  APIs

•  rte_tqs_create – creates a TQS variable

•  rte_tqs_start – triggers the readers to inform the writer about completion of

‘n’ number of quiescent states

•  rte_tqs_get – checks if the threads have passed through ‘n’ number of

quiescent states

•  rte_tqs_update – called by the data plane threads to update the tqs state

•  rte_tqs_delete – free tqs checker entry

Page 16: Lock Free RW Concurrency in hash library - Home - DPDK

16

Plans for upstreaming

•  Lock Free RW concurrency patch will be sent to mailing list for

review (beginning of next week) – Targeting 18.11

•  TQS library – High Level Design, API definition - Done

•  Coding/Testing need to happen – Targeting Q4 for 1st patch

Page 17: Lock Free RW Concurrency in hash library - Home - DPDK

Questions?

Page 18: Lock Free RW Concurrency in hash library - Home - DPDK

18

Scaling with Lock Free RW concurrency

•  Numbers with patch

0 50 100 150 200 250 300 350

2

4

6

8

10

12

Lookupperformancewithandwithoutadd

Lookup Lookupwithadd