Abstract-In commercial-off-the-shelf (COTS) multi-core systems, a task running on one core can be delayed by other tasks running simultaneously on other cores due to interference in the shared DRAM main memory. Such memory interference delay can be large and highly variable, thereby posing a significant challenge for the design of predictable real-time systems. In this paper, we present techniques to provide a tight upper bound on the worst-case memory interference in a COTS-based multi-core system. We explicitly model the major resources in the DRAM system, including banks, buses and the memory controller. By considering their timing characteristics, we analyze the worstcase memory interference delay imposed on a task by other tasks running in parallel. To the best of our knowledge, this is the first work bounding the request re-ordering effect of COTS memory controllers. Our work also enables the quantification of the extent by which memory interference can be reduced by partitioning DRAM banks. We evaluate our approach on a commodity multi-core platform running Linux/RK. Experimental results show that our approach provides an upper bound very close to our measured worst-case interference.

No abstract

In commercial-off-the-shelf (COTS) multi-core systems, the execution times of tasks become hard to predict because of contention on shared resources in the memory hierarchy. In particular, a task running in one processor core can delay the execution of another task running in another processor core. This is due to the fact that tasks can access data in the same cache set shared among processor cores or in the same memory bank in the DRAM memory (or both). Such cache and bank interference effects have motivated the need to create isolation mechanisms for resources accessed by more than one task. One popular isolation mechanism is cache coloring that divides the cache into multiple partitions. With cache coloring, each task can be assigned exclusive cache partitions, thereby preventing cache interference from other tasks. Similarly, bank coloring allows assigning exclusive bank partitions to tasks. While cache coloring and some bank coloring mechanisms have been studied separately, interactions between the two schemes have not been studied. Specifically, while memory accesses to two different bank colors do not interfere with each other at the bank level, they may interact at the cache level. Similarly, two different cache colors avoid cache interference but may not prevent bank interference. Therefore it is necessary to coordinate cache and bank coloring approaches. In this paper, we present a coordinated cache and bank coloring scheme that is designed to prevent cache and bank interference simultaneously. We also developed color allocation algorithms for configuring a virtual memory system to support our scheme which has been implemented in the Linux kernel. In our experiments, we observed that the execution time can increase by 60% due to inter-task interference when we use only cache coloring. Our coordinated approach can reduce this figure down to 12% (an 80% reduction).

accelerated by the readily-available hardware platforms, as well as This paper presents the design principles, implementation, and core system software such as sensor node operating systems in evaluation of the RETOS operating system which is specifically particular. From the early days, much effort has been given to developed for micro sensor nodes. RETOS has four distinct develop efficient and yet complete operating systems for micro objectives, which are to provide (1) a multithreaded programming sensor nodes. For instance, TinyOS [1] has historically been used by interface, (2) system resiliency, (3) kerel extensibility with many practitioners in the field and even advocated as "the" dynamic reconfiguration, and (4) WSN-oriented network operating system for WSN. Other operating systems such as abstraction. RETOS is a multithreaded operating system, hence it SOS[2], Contiki[3], MANTIS[4], and t-kernel[5] have challenged provides the commonly used thread model of programming the success of TinyOS and provide incremental, or even alternative interface to developers. We have used various implementation solutions for many practical issues still being debated in the related techniques to optimize the performance and resource usage of communities.multithreading. RETOS also provides software solutions to separate Writing an operating system for micro sensor platforms poses kernel from user applications, and supports their robust execution on several unprecedented problems. First, the OS implementation MMU-less hardware. The RETOS kernel can be dynamically should consider microcontrollers which typically provide very reconfigured, via loadable kernel framework, so a applicationlimited processing power, memory and battery life-time. The eventoptimized and resource-efficient kernel is constructed. Finally, the driven paradigm for sensor OS is especially favored for the networking architecture in RETOS is designed with a layering resource-constrained environment, and we have seen the concept to provide WSN-specific network abstraction. RETOS proliferation of TinyOS or SOS in this context. Second, the currently supports Atmel ATmegal28, TI MSP430, and Chipcon application programming model should be seriously considered to CC2430 family of microcontrollers. Several real-world WSN provide an easy and convenient programming interface to applications are developed for RETOS and the overall evaluation of application developers, without needing to be aware of underlying the systems is described in the paper.operating system principles. The event-driven operating systems, for example, enforce programmers to structure and program an Categories and Subject Descriptors application as a state machine in terms of tasks and event handlers. D.4.7 [Operating systems]: Organization and DesignUnderstanding this concept is an easy task for experts, but conventional programmers who are accustomed to a process model General Terms of programming may find the concept hard to grasp. Third, a micro Design,eralerimentation, Measurement, Perfonnan...

No abstract

No abstract

No abstract

Lipopolysaccharide (LPS),