The Experts below are selected from a list of 585 Experts worldwide ranked by ideXlab platform
Valero Cortés Mateo - One of the best experts on this subject based on the ideXlab platform.
-
Measuring operating system overhead on Sun UltraSparc T1 processor
2009Co-Authors: Radojkovic Petar, Cakarevic Vladimir, Verdú Mulà Javier, Pajuelo González, Manuel Alejandro, Gioiosa Roberto, Cazorla Almeida, Francisco Javier, Nemirovsky Mario, Valero Cortés MateoAbstract:Numerous studies have shown that Operating System (OS) noise is one of the reasons for significant performance degradation in clustered architectures. Although many studies examine the OS noise for High Performance Computing, especially in multi-processor/core systems, most of them focus on 2- or 4-core systems. In this study, we analyze sources of OS noise on a massive multithreading processor, the Sun UltraSPARC T1.We compare results, measured in Linux and Solaris, with the results provided by a low-overhead runtime environment that introduces almost no overhead in applications’ execution time. Our results show that the overhead introduced by the OS Timer Interrupt in Linux and Solaris depends on the particular core and hardware context in which the application is running. This overhead is up to 30% when the application is executed on the same hardware context as the Timer Interrupt handler, and up to 10% when the application and the Timer Interrupt handler run on different contexts but on the same core. We detect no overhead when the benchmark and the Timer Interrupt handler run on different cores of the processor.Postprint (published version
-
Measuring operating system overhead on CMT processors
'Institute of Electrical and Electronics Engineers (IEEE)', 2008Co-Authors: Radojkovic Petar, Cakarevic Vladimir, Verdú Mulà Javier, Pajuelo González, Manuel Alejandro, Gioiosa Roberto, Cazorla Almeida, Francisco Javier, Nemirovsky Mario, Valero Cortés MateoAbstract:Numerous studies have shown that Operating System (OS) noise is one of the reasons for significant performance degradation in clustered architectures. Although many studies examine the OS noise for High Performance Computing (HPC), especially in multi-processor/core systems, most of them focus on 2- or 4-core systems. In this paper, we analyze the major sources of OS noise on a massive multithreading processor, the Sun UltraSPARC T1, running Linux and Solaris. Since a real system is too complex to analyze, we compare those results with a low-overhead runtime environment: the Netra Data Plane Software Suite (Netra DPS). Our results show that the overhead introduced by the OS Timer Interrupt in Linux and Solaris depends on the particular core and hardware context in which the application is running. This overhead is up to 30% when the application is executed on the same hardware context of the Timer Interrupt handler and up to 10% when the application and the Timer Interrupt handler run on different contexts but on the same core. We detect no overhead when the benchmark and the Timer Interrupt handler run on different cores of the processor.Peer ReviewedPostprint (published version
-
Measuring operating system overhead on CMT processors
'Institute of Electrical and Electronics Engineers (IEEE)', 2008Co-Authors: Radojkovic Petar, Cakarevic Vladimir, Verdú Mulà Javier, Pajuelo González, Manuel Alejandro, Gioiosa Roberto, Cazorla Almeida, Francisco Javier, Nemirovsky Mario, Valero Cortés MateoAbstract:Numerous studies have shown that Operating System (OS) noise is one of the reasons for significant performance degradation in clustered architectures. Although many studies examine the OS noise for High Performance Computing (HPC), especially in multi-processor/core systems, most of them focus on 2- or 4-core systems. In this paper, we analyze the major sources of OS noise on a massive multithreading processor, the Sun UltraSPARC T1, running Linux and Solaris. Since a real system is too complex to analyze, we compare those results with a low-overhead runtime environment: the Netra Data Plane Software Suite (Netra DPS). Our results show that the overhead introduced by the OS Timer Interrupt in Linux and Solaris depends on the particular core and hardware context in which the application is running. This overhead is up to 30% when the application is executed on the same hardware context of the Timer Interrupt handler and up to 10% when the application and the Timer Interrupt handler run on different contexts but on the same core. We detect no overhead when the benchmark and the Timer Interrupt handler run on different cores of the processor.Peer Reviewe
Frederic T Chong - One of the best experts on this subject based on the ideXlab platform.
-
temporal search detecting hidden malware timebombs with virtual machines
Architectural Support for Programming Languages and Operating Systems, 2006Co-Authors: Jedidiah R Crandall, Gary Wassermann, Daniela Oliveira, Zhendong Su, Felix S Wu, Frederic T ChongAbstract:Worms, viruses, and other malware can be ticking bombs counting down to a specific time, when they might, for example, delete files or download new instructions from a public web server. We propose a novel virtual-machine-based analysis technique to automatically discover the timetable of a piece of malware, or when events will be triggered, so that other types of analysis can discern what those events are. This information can be invaluable for responding to rapid malware, and automating its discovery can provide more accurate information with less delay than careful human analysis.Developing an automated system that produces the timetable of a piece of malware is a challenging research problem. In this paper, we describe our implementation of a key component of such a system: the discovery of Timers without making assumptions about the integrity of the infected system's kernel. Our technique runs a virtual machine at slightly different rates of perceived time (time as seen by the virtual machine), and identifies time counters by correlating memory write frequency to Timer Interrupt frequency.We also analyze real malware to assess the feasibility of using full-system, machine-level symbolic execution on these Timers to discover predicates. Because of the intricacies of the Gregorian calendar (leap years, different number of days in each month, etc.) these predicates will not be direct expressions on the Timer but instead an annotated trace; so we formalize the calculation of a timetable as a weakest precondition calculation. Our analysis of six real worms sheds light on two challenges for future work: 1) time-dependent malware behavior often does not follow a linear timetable; and 2) that an attacker with knowledge of the analysis technique can evade analysis. Our current results are promising in that with simple symbolic execution we are able to discover predicates on the day of the month for four real worms. Then through more traditional manual analysis we conclude that a more control-flow-sensitive symbolic execution implementation would discover all predicates for the malware we analyzed.
Roberto Gioiosa - One of the best experts on this subject based on the ideXlab platform.
-
Measuring operating system overhead on Sun UltraSparc T1 processor
2009Co-Authors: Petar Radojkovic, Vladimir Cakarevic, Javier Verdú Mulà, Manuel Alejandro Pajuelo González, Francisco Javier Cazorla Almeida, Roberto Gioiosa, Mario Nemirovsky, Mateo Valero CortésAbstract:Numerous studies have shown that Operating System (OS) noise is one of the reasons for significant performance degradation in clustered architectures. Although many studies examine the OS noise for High Performance Computing, especially in multi-processor/core systems, most of them focus on 2- or 4-core systems. In this study, we analyze sources of OS noise on a massive multithreading processor, the Sun UltraSPARC T1.We compare results, measured in Linux and Solaris, with the results provided by a low-overhead runtime environment that introduces almost no overhead in applications’ execution time. Our results show that the overhead introduced by the OS Timer Interrupt in Linux and Solaris depends on the particular core and hardware context in which the application is running. This overhead is up to 30% when the application is executed on the same hardware context as the Timer Interrupt handler, and up to 10% when the application and the Timer Interrupt handler run on different contexts but on the same core. We detect no overhead when the benchmark and the Timer Interrupt handler run on different cores of the processor.
-
Abstract Transparent, Incremental Checkpointing at Kernel Level: a Foundation for Fault Tolerance for Parallel Computers
2008Co-Authors: Roberto Gioiosa, Kei DavisAbstract:We describe the software architecture, technical features, and performance of TICK (Transparent Incremental Checkpointer at Kernel level), a system-level checkpointer implemented as a kernel thread, specifically designed to provide fault tolerance in Linux clusters. This implementation, based on the 2.6.11 Linux kernel, provides the essential functionality for transparent, highly responsive, and efficient fault tolerance based on full or incremental checkpointing at system level. TICK is completely user-transparent and does not require any changes to user code or system libraries; it is highly responsive: an Interrupt, such as a Timer Interrupt, can trigger a checkpoint in as little as 2.5µs; and it supports incremental and full checkpoints with minimal overhead—less than 6 % with full checkpointing to disk performed as frequently as once per minute.
-
transparent incremental checkpointing at kernel level a foundation for fault tolerance for parallel computers
Conference on High Performance Computing (Supercomputing), 2005Co-Authors: Roberto Gioiosa, Jose Carlos Sancho, Song Jiang, Fabrizio Petrini, Kei DavisAbstract:We describe the software architecture, technical features, and performance of TICK (Transparent Incremental Checkpointer at Kernel level), a system-level checkpointer implemented as a kernel thread, specifi- cally designed to provide fault tolerance in Linux clusters. This implementation, based on the 2.6.11 Linux kernel, provides the essential functionality for transparent, highly responsive, and efficient fault tolerance based on full or incremental checkpointing at system level. TICK is completely user-transparent and does not require any changes to user code or system libraries; it is highly responsive: an Interrupt, such as a Timer Interrupt, can trigger a checkpoint in as little as 2.5µs; and it supports incremental and full checkpoints with minimal overhead-less than 6% with full checkpointing to disk performed as frequently as once per minute.
Kei Davis - One of the best experts on this subject based on the ideXlab platform.
-
Abstract Transparent, Incremental Checkpointing at Kernel Level: a Foundation for Fault Tolerance for Parallel Computers
2008Co-Authors: Roberto Gioiosa, Kei DavisAbstract:We describe the software architecture, technical features, and performance of TICK (Transparent Incremental Checkpointer at Kernel level), a system-level checkpointer implemented as a kernel thread, specifically designed to provide fault tolerance in Linux clusters. This implementation, based on the 2.6.11 Linux kernel, provides the essential functionality for transparent, highly responsive, and efficient fault tolerance based on full or incremental checkpointing at system level. TICK is completely user-transparent and does not require any changes to user code or system libraries; it is highly responsive: an Interrupt, such as a Timer Interrupt, can trigger a checkpoint in as little as 2.5µs; and it supports incremental and full checkpoints with minimal overhead—less than 6 % with full checkpointing to disk performed as frequently as once per minute.
-
transparent incremental checkpointing at kernel level a foundation for fault tolerance for parallel computers
Conference on High Performance Computing (Supercomputing), 2005Co-Authors: Roberto Gioiosa, Jose Carlos Sancho, Song Jiang, Fabrizio Petrini, Kei DavisAbstract:We describe the software architecture, technical features, and performance of TICK (Transparent Incremental Checkpointer at Kernel level), a system-level checkpointer implemented as a kernel thread, specifi- cally designed to provide fault tolerance in Linux clusters. This implementation, based on the 2.6.11 Linux kernel, provides the essential functionality for transparent, highly responsive, and efficient fault tolerance based on full or incremental checkpointing at system level. TICK is completely user-transparent and does not require any changes to user code or system libraries; it is highly responsive: an Interrupt, such as a Timer Interrupt, can trigger a checkpoint in as little as 2.5µs; and it supports incremental and full checkpoints with minimal overhead-less than 6% with full checkpointing to disk performed as frequently as once per minute.
Quaglia Francesco - One of the best experts on this subject based on the ideXlab platform.
-
A fine-grain time-sharing Time Warp system
'Association for Computing Machinery (ACM)', 2017Co-Authors: Pellegrini Alessandro, Quaglia FrancescoAbstract:Although Parallel Discrete Event Simulation (PDES) platforms 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
-
Time-Sharing Time Warp via Lightweight Operating System Support
'Association for Computing Machinery (ACM)', 2015Co-Authors: Pellegrini Alessandro, Quaglia FrancescoAbstract:The order according to which the different tasks are carried out within a Time Warp platform has a direct impact on performance, given that event processing is speculative, thus being subject to the possibility of being rolled-back. It is typically recognized that not-yet-executed events having lower timestamps should be given higher CPU-schedule priority, since this contributes to keep low the amount of rollbacks. However, common Time Warp platforms usually execute events as atomic actions. Hence control is bounced back to the underlying simulation platform only at the end of the current event processing routine. In other words, CPU-scheduling of events resembles classical batch-multitasking scheduling, which is recognized not to promptly react to variations of the priority of pending tasks (e.g. associated with the injection of new events in the system). In this article we present the design and implementation of a time-sharing Time Warp platform, to be run on multi-core machines, where the platform-level software is allowed to take back control on a periodical basis (with fine grain period), and to possibly preempt any ongoing event processing activity in favor of dispatching (along the same thread) any other event that is revealed to have higher priority. Our proposal is based on an ad-hoc kernel module for Linux, which implements a fine grain Timer-Interrupt mechanism with lightweight management, which is fully integrated with the modern top/bottom-half Timer-Interrupt Linux architecture, and which does not induce any bias in terms of relative CPU-usage planning across Time Warp vs non-Time Warp threads running on the machine. Our time-sharing architecture has been integrated within the open source ROOT-Sim optimistic simulation package, and we also report some experimental data for an assessment of our proposal