Prompt Application-Transparent Transaction Revalidation in Software Transactional Memory Simone Emiliano Pierangelo Alessandro Economo Silvestri Di Sanzo Pellegrini DIAG – Sapienza University of Rome Francesco Quaglia DICII – University of Rome Tor Vergata
Software Transactional Memory • 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
STM properties • 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
Problem Definition • 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)
Objective • 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
Our approach Application Early aborts Transaction revalidation STM Revalidations Tick filtering OS Extra ticks Tick generation Hardware
Tick generation • 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 Extra ticks
Tick filtering • 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)
Transaction revalidation • 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
Tackling the problem at hand
Experimental setting • 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
Benchmark • 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 ID Profile CPU Demand % mix 1 ≈ 350 μsec 49% new order 2 payment < 10 μsec 43% 3 order status ≈ 10 μsec 4% 4 ≈ 650 μsec 4% stock level * As per TPC-C specification, it can be executed in deferred mode
Experimental results Turnaround time per profile relative to baseline Average system throughput PR = Prompt Revalidation OVH-ET = Overhead of Extra-Tick (no revalidation) s X = X extra-ticks per reference timer period
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?
OS extra-tick handler logic • 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
STM 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
The timestretch Linux kernel module • 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)
LAPIC-timer and extra-ticks
Recommend
More recommend
