Prompt Application-Transparent Transaction Revalidation in Software - - PowerPoint PPT Presentation

Simone Economo

Prompt Application-Transparent Transaction Revalidation in Software Transactional Memory

Emiliano Silvestri Pierangelo Di Sanzo Alessandro Pellegrini Francesco Quaglia DIAG – Sapienza University of Rome DICII – University of Rome Tor Vergata

• An abstraction to simplify concurrent programming

─ Manages concurrent accesses to shared-data inside transactions ─ Provides transactions with atomicity and isolation guarantees

• Main objectives

─ Transparency → Make it as “simple” as coarse-grained locking ─ Efficiency → Make it as “fast” as fine-grained locking

• Major research trends

─ Transaction scheduling techniques ─ Thread scheduling techniques ─ Contention management policies

Software Transactional Memory

• Safety

─ A transaction always sees and leaves memory in a consistent state ─ Strictly defined by a correctness requisite (e.g., opacity)

• Liveness

─ A transaction is eventually able to terminate successfully ─ Strictly defined by a progress condition (e.g., obstruction freedom)

• A means to ensure safety is validation

─ Checks that a transaction is valid at a certain point in time ─ If not, the transaction can be aborted and restarted

STM properties

• STM validation is not timely

─ Validations are only performed conservatively (e.g., upon read or write)

Problem Definition

• STM validation is not timely

─ Validations are only performed conservatively (e.g., after read or write) ─ If tx is running and a conflict arises, tx is doomed to abort...

Problem Definition

• STM validation is not timely

─ Validations are only performed conservatively (e.g., after read or write) ─ If tx is running and a conflict arises, tx is doomed to abort... ─ ...but the STM layer may not detect the conflict for a while!

Problem Definition

• Sub-optimal performance-energy configuration

─ Effects on turnaround (since aborts are detected lazily) ─ Effects on energy efficiency (CPU time wasted for doomed work)

Problem Definition

• Application-transparent prompt revalidation of transactions

Transparent It must not be in charge of application programmers Efficient It must be lightweight and unobtrusive Timely It must react promptly to conflicts Portable It must be independent of the workload

• No implications on correctness, performance only
• Common literature approaches have flaws

─ User-space signals (e.g., POSIX signals)

• Too coarse granularity with respect to transaction completion times

─ User-Level Threads

• Timeliness is a function of the implementation
• Not always suited for full transparency

Objective

Our approach

Tick generation Tick filtering Transaction revalidation

OS STM Hardware Application

Early aborts Revalidations Extra ticks

• Uses fine-grain periodical hardware-timer interrupts

─ The original OS timer period is split into fine-grain ticks (extra-ticks)

• By scaling down the LAPIC-timer value of a CPU core

─ Each delivered extra-tick interrupts the running thread

• An APIC interrupt, to be processed as soon as possible

─ The OS kernel handles the interrupt via an extra-tick handler

• Like the original OS timer interrupt, but with augmented facilities
• The original OS planning of CPU time to threads is not altered

Tick generation

Extra ticks

• The current extra-tick is discarded if

─ The interrupted thread is not running a transaction

• Application code, but not transactional

─ The running transaction is surely consistent

• Using an O(1) predicate with inputs, if any, provided by the STM layer

─ The running transaction has been recently validated

• By the STM layer in between two consecutive extra-ticks

─ The running transaction is executing unsafe code

• Non-application code (e.g., third-party code)
• The extra-tick will be processed asynchronously (see later)

Tick filtering

• A callback function is prepared for execution

─ When the thread is resumed userspace, the callback is invoked ─ Simulates a static function call (except it's dynamic!)

• The callback performs a transaction revalidation

─ As opposed to normal validation (performed by the STM layer) ─ If a conflict is detected, an early abort is produced leading to a rollback

• Transaction revalidation can be asynchronous

─ Will be performed as soon as possible upon returning from unsafe code ─ Requested by the OS using a memory region shared with the STM

Transaction revalidation

Tackling the problem at hand

• 64-bit NUMA HP ProLiant Server

─ 4×2GHz AMD Opteron 6128 processors, 8 cores each ─ 64GB RAM ─ OpenSuse 13.2 (x86-64) with Kernel 3.16.7

• TinySTM client-server with

─ 6 client threads for submitting requests

• at maximum sustainable capacity (full load)

─ 6 server threads for receiving requests

• a backlog of 4094 incoming requests

─ 8/16/24 STM threads for running transactions

• 1M/2M/3M total transactions executed

─ 5, 10 and 20 extra-ticks per original time period

• corresponding to 200, 100 and 50 μsec between extra-ticks

Experimental setting

• TPC-C 5.11 w/o delivery *

─ Representative of OLTP workloads ─ Simulate a whole-sale supplying items from a set of warehouses to customers within sale districts

Benchmark

ID Profile CPU Demand % mix 1 new order ≈ 350 μsec 49% 2 payment < 10 μsec 43% 3

• rder status

≈ 10 μsec 4% 4 stock level ≈ 650 μsec 4%

* As per TPC-C specification, it can be executed in deferred mode

Experimental results

Turnaround time per profile relative to baseline

PR = Prompt Revalidation OVH-ET = Overhead of Extra-Tick (no revalidation) sX = X extra-ticks per reference timer period

Average system throughput

Experimental results

Number of validations + revalidations per profile (excluded commit-time validations) Number of aborts per profile relative to baseline

Comments and future plans

• Our filtering mechanism can be improved

─ 1% to 45% of extra-ticks are discarded ─ 25% to 50% of revalidations succeed

• A mathematical model can be used

─ Compute the probability of conflicts ─ Estimate the optimal revalidation point (if any) ─ Wait for it before firing a revalidation

• Revalidation can serve other transactional systems

─ e.g., in-memory databases ─ All those where validation is needed to ensure safety

Thank you! Questions?

• Upon an extra-tick timer interrupt, the kernel

─ Checks if the interrupted threads is in a transactional context

• else returns

─ Checks if the transaction is surely consistent via an O(1) check

• if so, returns

─ Checks if the transaction has been recently validated

• if so, returns

─ Checks if the interrupted threads is in a safe code zone

• else notifies the STM layer that the tick is standing and returns

─ Installs the user-space callback

• Performs an O(n) user-space revalidation of transactions

OS extra-tick handler logic

• Upon a transactional read/write the STM

─ Checks if it there is any standing tick

• If so, revalidates the transaction (asynchronous tick processing)
• Upon a STM validation

─ Checks if the validation succeeds

• If so, notifies the OS that a validation has been recently performed

STM logic

• Provides an extra-tick delivery service

─ Exposes a pseudo-device to start/stop per-thread extra-tick delivery

• Threads can register to it to request the delivery of extra-ticks

─ Associates a control buffer to each thread

• Used as a shared memory region between the STM and the OS

─ Accepts a scale parameter to divide the original OS timer period

• Extra-tick period = Original OS timer / scale parameter

─ Accepts a callback function to be invoked upon extra-tick delivery

• In our case, a STM transaction validation service plus abort (if required)

The timestretch Linux kernel module

LAPIC-timer and extra-ticks