Upload
althea-hill
View
16
Download
2
Embed Size (px)
DESCRIPTION
Synchronization Aware Conflict Resolution for Runtime Monitoring using Transactional Memory. Chen Tian, Vijay Nagarajan, Rajiv Gupta April 6, 2008. load A, R1. Mem. store ins Meta-data for A. Shadow Mem. store R2, B. store ins Meta-data for B. Actual instruction sequence. - PowerPoint PPT Presentation
Citation preview
Synchronization Aware Conflict Resolution for Runtime Monitoring using
Transactional Memory
Chen Tian, Vijay Nagarajan, Rajiv Gupta
April 6, 2008
Runtime Monitoring
Useful in many placesdebugging, profiling, security
Dynamic binary translation tools -DBTExample: Pin, Valgrind
Main task: instrumentation
load A, R1
store R2, B Mem.
Mem.
storeins Meta-data for A
storeins Meta-data for B
Shadow Mem.
Shadow Mem.
Actual instruction sequence
loadins r2, Xincins r2, 1
loadins r1, Xincins r1, 1
storeins r2 , X
Monitoring on Multicore MachineRace problem
Core 1
storeins r1 , X
load1 …
Core 2
load2 …
Wrong !
Solution ? Transactional memory - TM (J. Chung et al. HPCA’ 08)
Conflict !
start_tranx
end_tranx
start_tranx
end_tranx
Transaction sizenew instruction overhead VS abort overhead
Overhead and Transaction Size
Creating a transaction per basic block worst performance (over 60%)
Larger transaction is preferredTrace granularity and dynamic merging
0
5
10
15
20
25
Barnes Fmm Ocean-1 Ocean-2 Radiosity Raytrace Volrend
Ove
rhea
d (
per
cen
t)
4-BB
8-BB
12-BB
More about TM systemHardware and Software
This work focus on hardware - HTM
3 key functions:Memory version managementConflict detection
cache coherence message (HTM)
Conflict resolution
3 existing HTM designsEE – eager detection, requester losesEL – eager detection, requester winsLL – lazy detection, committer wins
start_tranx
end_tranx
Live Lock Problem
Example
start_tranx
end_tranx
…while (flag != 1) ;…
…flag = 1;…
…while (flag1 != 1) ;flag2 = 1;…
…flag1 = 1;while (flag2 != 1) ;…
ReasonDBT tools put the sync. into transactions
Especially for busy-waiting sync.
HTM doesn’t know the conflict is caused by sync.Fix it by making HTM sync.-aware
Core 1 Core 2
Abort!
EE Policy:Requester loses
Busy-waiting Synchronization Pattern
Spinning read and a remote writeFlag sync., locks, barriers
No !No !
Can I go?
Now you can go!
Yes !
Yes !
Remote Write
Spinning Read
Spinning read: a load repeated X times
Remote write: value changed by another thread
Hardware Implementation
Load table, Detector, Synchronization TableSimulated on Simics
New Conflict Resolution
Key idea:
A transaction which performs the
sync. write should be committed immediately!
Add two rulesWhen a sync. pattern is detected, notify the HTM
(avoid or break live locks due to sync.)
When a conflict is detected, check the syn_table
(ensure discovered sync. will not cause live locks )
...end_tranx
start_tranx…
start_tranx…flag = 1;end_tranx
Example
start_tranx
end_tranx
…while (flag != 1) ;…
end_tranx
…flag = 1;…
start_tranx
Synchronization
Detected!Abort!
Transaction 1 Transaction 2
When T1 comes again, it will see the updated
value of flag.
Accuracy of Sync. Detector
Splash-2 Programs
Actual No. Detected No.
Barnes 33 33
Fmm 59 55
Ocean-noncont. 44 44
Ocean-cont. 42 42
Radiosity 60 60
Raytrace 19 19
Volrend 35 35
Water-ns 24 24
Water-sp 28 28
Comparison with Time-out
Time-out solutionPeriodically check the progress
Re-instrumentation on the fly
Pay extra overhead (conflict may only happen once)
Our solution (relies on HTM, not DBT)No need for re-instrumentation
Only need to check when there is conflict
Thanks !
Any Questions?