Kernel-Assisted Scheduling and Deadline Support for Software Transactional Memory

Kernel-Assisted Scheduling and Deadline Support for Software

Transactional Memory

Walther Maldonado, Patrick Marlier, Pascal Felber, Etienne Rivière

University of Neuchâtel, Switzerland

Julia Lawall (DIKU, Denmark)

Gilles Muller (INRIA, France)

Kernel-Assisted Scheduling and Deadline Support for Software Kernel-Assisted Scheduling and Deadline Support for Software Transactional MemoryTransactional Memory

Problems

● Target : situations where conflicts degrade performance because of how transactions are scheduled

● Two scenarios considered :● Performance on high-contention settings

(i.e.: large number of threads)● Responsiveness for reactive applications


High contention scenario

● Long transactions abort frequently

S ✘

S ✔

✘ ✘R R ✘ R

T2

T1

S S ✔✔

S ✔

T3

T4


High contention scenario

● Transactions which re-execute immediately are likely to abort again...

● ...but exponential back-offs are imprecise

S ✘

S S S S ✔✔✔✔

✘R R ✘ R

T1

T2

S ✘

S S

✔✘

✔ ✔

✘✘ ✔ ✘ ✘

T1

T2

R✘

✘✘ S ✘


Deadlines & Real Time

● Reactive (soft real time ) applications have time constraints

● Quality of Service : acceptable miss rate● Example : Rendering

● Target : 60 fps , deadline : 16ms / frame● We need an acceptable QoS for the reactive

transaction (s)● QoS : 95% (57 fps)● QoS : 80% (48 fps)

● Minimize penalty on other (computing) transactions


Scheduling Approach

● Add Serializing Contention Managers to TinySTM● Hard Serializing● Soft Serializing

● Add Linux kernel specific support ● Time Slice extensions

ContributionsContributions


Serializing

● Conflict bookkeeping

● Hard Serializing (kernel queue)

● Soft Serializing (yield + priority)


S

S ✔T1

T2

✘ R ✔

S

S ✔T1

T2

✘ R ✔Reschedule /yield


Time Slice Extensions

● Time-Slice Extension


ST1

✘ ✔

ST1

✔ Yield


Considerations for Deadlines

● Hypothesis:● Stable transaction length● Only one thread with deadlines

● Approach based on changing execution modes on abort depending on remaining time before the deadline


OPT VR IVC

← throughputpredictability →


Optimistic (OPT)


S

S ✔T1

T2

✘

WR

R

OPT VR IVC

Highest throughputLow overheadFast readsDoes not detect R/W conflicts until commit

← throughputpredictability →


Visible Reads (VR)


S(VR)

ST1

T2

✔

R

R

✘W→

← throughput predictability →

OPT VR IVC

Reads can be seen by other transactionsEnables detecting R/W conflictsHigh overhead for Reads


Irrevocable (IVC)


S(IVC)

ST1

T2

✔

WR

R

ST4

R ✔

S(RO)T3

R ✔

✘

← throughput predictability →

OPT VR IVC

Ensures commitLowest overheadEnables RO transactions to commitHinders parallelism

Implementation

• Monitoring of transaction execution time• Keep previous 10 000 executions

• Time slice extension at the kernel level• Disable time sampling in case of preemption

• Adaptive run-time system implemented in TinySTM


Results at a glance

● Scheduling: less or no degradation when the number of thread increases

● Performance varies widely based on workload● Future work → a workload adapting contention

manager

● Soft-realtime: less degradation of non-real time transactions while maintaining 99% success rate for the real-time one

● Future work → support of multiple threads with deadlines


Detailed results

PP0PP 2010

Scheduling support for transactional memory contention management

DSN 2011

Deadline-Aware Scheduling for Software Transactional Memory


Documents

Kernel-Assisted Scheduling and Deadline Support for Software Transactional Memory