A Fine-Grain Time-Sharing Time Warp System

Abstract

relying on the Time Warp (optimistic) synchronization protocol already allow for exploiting parallelism, several techniques have been proposed to further favor performance. Among them we can mention optimized approaches for state restore, as well as techniques for load balancing or (dynamically) controlling the speculation degree, the latter being specifically targeted at reducing the incidence of causality errors leading to waste of computation. However, in state of the art Time Warp systems, events' processing is not preemptable, which may prevent the possibility to promptly react to the injection of higher priority (say lower timestamp) events. Delaying the processing of these events may, in turn, give rise to higher incidence of incorrect speculation. In this article we present the design and realization of a fine-grain time-sharing Time Warp system, to be run on multi-core Linux machines, which makes systematic use of event preemption in order to dynamically reassign the CPU to higher priority events/tasks. Our proposal is based on a truly dual mode execution, application vs platform, which includes a timer-interrupt based support for bringing control back to platform mode for possible CPU reassignment according to very fine grain periods. The latter facility is offered by an ad-hoc timer-interrupt management module for Linux, which we release, together with the overall time-sharing support, within the open source ROOT-Sim platform. An experimental assessment based on the classical PHOLD benchmark and two real world models is presented, which shows how our proposal effectively leads to the reduction of the incidence of causality errors, as compared to traditional Time Warp, especially when running with higher degrees of parallelism.

Prompt application-transparent transaction revalidation in software transactional memory

“…To achieve this, a thread must request extra-tick deliveries to the kernel by explicitly registering itself via the ioctl() system call. Benchmarking data provided in [3] show that this module induces negligible overhead for extra-tick deliveries on commodity hardware, even under very short extra-tick periods of the order of 50 microseconds. In the experimental section we report further overhead data when using extra-ticks as exploited in our STM-oriented management mechanism.…”

“…2) The dev_extra_tick Linux Module: Another component we exploit in our architecture, although in a re-devised version suited for our purposes, is the dev_extra_tick Linux loadable module presented in [3]. It allows to dynamically control the LAPIC-timer on board of x86 processors to enable the original operating system tick assigned to a thread to be partitioned into finer grain extra-ticks, according to a configurable scale parameter.…”

“…The purpose of these wrappers is to check if there is a standing tick and invoke the revalidation task, if the flag is raised, upon function return. In other words, this scheme leads our architecture to process an extratick-which could not be delivered synchronously-as soon as possible, i.e., right before returning control to the application code after an invocation to some STM function 3 . In this way, the rhythm of fine-grain revalidations tends to be preserved independently of the interleaving between application and environmental software along the same thread.…”

Porting Event &Cross-State Synchronization to the Cloud

“…Having a separate stack for every LP within a single worker thread (which has its own system stack) ensures the correctness of the preëmptive event execution. For a thorough technical description of the approach used to realize this facility in an application-transparent manner, we refer the reader to [19]. With respect to point ii) above, the state machine reported in Figure 3 has three different types of states: blocked states (grayshaded) are associated with a LP which has been descheduled while executing an event, thanks to the ULT facility; ready states (whitecolored) are associated with LPs which can be activated, either to start processing a new event, or to resume the execution of a preëmpted event; running states, which are associated with LPs currently executing an event.…”

Guest Editorial for the TOMACS Special Issue on the Principles of Advanced Discrete Simulation (PADS)

“…The following three special issue articles are on optimistic PDES. The article by Pellegrini and Quaqlia [2017] is on improving the performance of PDES platforms that rely on the Time Warp synchronization protocol. Towards this, they implement a fine-grain time-sharing Time Warp architecture, which makes systematic use of event preemption in order to dynamically reassign CPU time to higher-priority events/tasks.…”