Reducing Overhead in Microkernel Based Multiserver Operating Systems Through Register Banks
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Demystifying the Real-Time Linux Scheduling Latency
Demystifying the Real-Time Linux Scheduling Latency Daniel Bristot de Oliveira Red Hat, Italy [email protected] Daniel Casini Scuola Superiore Sant’Anna, Italy [email protected] Rômulo Silva de Oliveira Universidade Federal de Santa Catarina, Brazil [email protected] Tommaso Cucinotta Scuola Superiore Sant’Anna, Italy [email protected] Abstract Linux has become a viable operating system for many real-time workloads. However, the black-box approach adopted by cyclictest, the tool used to evaluate the main real-time metric of the kernel, the scheduling latency, along with the absence of a theoretically-sound description of the in-kernel behavior, sheds some doubts about Linux meriting the real-time adjective. Aiming at clarifying the PREEMPT_RT Linux scheduling latency, this paper leverages the Thread Synchronization Model of Linux to derive a set of properties and rules defining the Linux kernel behavior from a scheduling perspective. These rules are then leveraged to derive a sound bound to the scheduling latency, considering all the sources of delays occurring in all possible sequences of synchronization events in the kernel. This paper also presents a tracing method, efficient in time and memory overheads, to observe the kernel events needed to define the variables used in the analysis. This results in an easy-to-use tool for deriving reliable scheduling latency bounds that can be used in practice. Finally, an experimental analysis compares the cyclictest and the proposed tool, showing that the proposed method can find sound bounds faster with acceptable overheads. 2012 ACM Subject Classification Computer systems organization → Real-time operating systems Keywords and phrases Real-time operating systems, Linux kernel, PREEMPT_RT, Scheduling latency Digital Object Identifier 10.4230/LIPIcs.ECRTS.2020.9 Supplementary Material ECRTS 2020 Artifact Evaluation approved artifact available at https://doi.org/10.4230/DARTS.6.1.3. -
Context Switch in Linux – OS Course Memory Layout – General Picture
ContextContext switchswitch inin LinuxLinux ©Gabriel Kliot, Technion 1 Context switch in Linux – OS course Memory layout – general picture Stack Stack Stack Process X user memory Process Y user memory Process Z user memory Stack Stack Stack tss->esp0 TSS of CPU i task_struct task_struct task_struct Process X kernel Process Y kernel Process Z kernel stack stack and task_struct stack and task_struct and task_struct Kernel memory ©Gabriel Kliot, Technion 2 Context switch in Linux – OS course #1 – kernel stack after any system call, before context switch prev ss User Stack esp eflags cs … User Code eip TSS … orig_eax … tss->esp0 es Schedule() function frame esp ds eax Saved on the kernel stack during ebp a transition to task_struct kernel mode by a edi jump to interrupt and by SAVE_ALL esi macro edx thread.esp0 ecx ebx ©Gabriel Kliot, Technion 3 Context switch in Linux – OS course #2 – stack of prev before switch_to macro in schedule() func prev … Schedule() saved EAX, ECX, EDX Arguments to contex_switch() Return address to schedule() TSS Old (schedule’s()) EBP … tss->esp0 esp task_struct thread.eip thread.esp thread.esp0 ©Gabriel Kliot, Technion 4 Context switch in Linux – OS course #3 – switch_to: save esi, edi, ebp on the stack of prev prev … Schedule() saved EAX, ECX, EDX Arguments to contex_switch() Return address to schedule() TSS Old (schedule’s()) EBP … tss->esp0 ESI EDI EBP esp task_struct thread.eip thread.esp thread.esp0 ©Gabriel Kliot, Technion 5 Context switch in Linux – OS course #4 – switch_to: save esp in prev->thread.esp -
Sensors: Sensing and Data Acquisidon
Sensors: Sensing and Data Acquisi3on Prof. Yan Luo For UMass Lowell 16.480/552 Sensors: Sensing and Data Acquisi3on 1 Prof. Yan Luo, UMass Lowell Outline • Sensors • Sensor interfacing • Sensor data conversion and acquisi3on • PIC microcontroller programming • Lab 1: Sensor design and data acquisi3on (a light intensity sensor) Sensors: Sensing and Data Acquisi3on 2 Prof. Yan Luo, UMass Lowell Basic Principle of Sensors • Transducer: a device that converts energy from one form to another • Sensor: converts a physical parameter to an electric output – Electric output is desirable as it enables further signal processing. • Actuator: coverts an electric signal to a physical output Sensors: Sensing and Data Acquisi3on 3 Prof. Yan Luo, UMass Lowell Sensors • Cameras • Analog sensors • Accelerometer - Con3nuously varying output • Rate gyro • Digital sensors • Strain gauge - on/off • Microphone - Pulse trains (freq convey measurement) • Magnetometer • Chemical sensors • Op3cal sensors Sensors: Sensing and Data Acquisi3on 4 Prof. Yan Luo, UMass Lowell Example: Photoresistor • Or Light Dependent Resistor (LDR) – Resistance decreases with increasing light intensity – Made of semiconductor – Photons absorbed cause electrons to jump into conduc3on band Sensors: Sensing and Data Acquisi3on 5 Prof. Yan Luo, UMass Lowell Interfacing with Sensors • Interface circuitry • ADC • Interfaces of the embedded system • SoVware drivers and APIs Sensors: Sensing and Data Acquisi3on 6 Prof. Yan Luo, UMass Lowell Example voltage divider circuit Vcc R2 V=Vcc x R1/(R1+R2) V R1 Sensors: Sensing and Data Acquisi3on 7 Prof. Yan Luo, UMass Lowell Analog-Digital Converter (ADC) • Types of ADC – Integrang ADC • Internal voltage controlled oscillator • slow – Successive approximaon ADC • Digital code driving the analog reference voltage – Flash ADC • A bank of comparators • Fast Sensors: Sensing and Data Acquisi3on 8 Prof. -
"Firefly" Z80 General-Purpose Retro Computing Platform
"FIREFLY" Z80 GENERAL-PURPOSE RETRO COMPUTING PLATFORM THREE FARTHING LABS http://www.threefarthing.com Page 1 of 13 PREFACE A project has to have a name and this one wound up being called "Firefly" as it©s the culmination of a wirewrap board begun several years ago while binge-watching the series of the same name. That board, in turn, was a redesign of a single board computer I created in 1998, creatively named the "SBCZ1." All three of these projects were begun as a chance to tinker with a processor I first met hands- on in 1984, the ZiLOG Z-80, though it was long-established by that time and dominated the business computer market. It was the CPU of preference behind most CP/M machines and CP/M was what I wanted to tinker with again, from the ground up ± not in some cozy emulator. When I began preparing to design the board I looked around on the Internet and found many excellent Z80 projects, including kit options. The choice was made to "roll my own" for numerous reasons. In the SBCZ1 I had most of a good design and wanted to retain a lot of hard work (done before I had Internet access, mind you). There were also specific reasons for wanting "to stay within ZiLOG canon" and work with a particular hardware configuration. I saw no kits that did just what I wanted in the way that I wanted. There was also a desire to maintain modularity and be extensible but not require a proliferation of modules for what I considered core functionality, yet great restraint was employed to keep "core functionality" spartan. -
What Is an Operating System III 2.1 Compnents II an Operating System
Page 1 of 6 What is an Operating System III 2.1 Compnents II An operating system (OS) is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function. Memory management Among other things, a multiprogramming operating system kernel must be responsible for managing all system memory which is currently in use by programs. This ensures that a program does not interfere with memory already in use by another program. Since programs time share, each program must have independent access to memory. Cooperative memory management, used by many early operating systems, assumes that all programs make voluntary use of the kernel's memory manager, and do not exceed their allocated memory. This system of memory management is almost never seen any more, since programs often contain bugs which can cause them to exceed their allocated memory. If a program fails, it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs or viruses may purposefully alter another program's memory, or may affect the operation of the operating system itself. With cooperative memory management, it takes only one misbehaved program to crash the system. Memory protection enables the kernel to limit a process' access to the computer's memory. Various methods of memory protection exist, including memory segmentation and paging. All methods require some level of hardware support (such as the 80286 MMU), which doesn't exist in all computers. -
Efficient Automated Code Partitioning for Microcontrollers with Switchable
Efficient Automated Code Partitioning for Microcontrollers with Switchable Memory Banks MICHAL CISZEWSKI and KONRAD IWANICKI, University of Warsaw 114 Switching active memory banks at runtime allows a processor with a narrow address bus to access memory that exceeds ranges normally addressable via the bus. Switching code memory banks is regaining interest in microcontrollers for the Internet of Things (IoT), which have to run continuously growing software, while at the same time consuming ultra-small amounts of energy. To make use of bank switching, such software has to be partitioned among the available banks and augmented with bank-switching instructions. In contrast to the augmenting, which is done automatically by a compiler, today the partitioning is normally done manually by programmers. However, since IoT software is cross-compiled on much more powerful machines than its target microcontrollers, it becomes possible to partition it automatically during compilation. In this article, we thus study the problem of partitioning program code among banks such that the resulting runtime performance of the program is maximized. We prove that the problem is NP-hard and propose a heuristic algorithm with a low complexity, so that it enables fast compilation, and hence interactive software development. The algorithm decomposes the problem into three subproblems and introduces a heuristic for each of them: (1) Which pieces of code to partition? (2) Which of them to assign to permanently mapped banks? and (3) How to divide the remaining ones among switchable banks? We integrate the algorithm, together with earlier ones, in an open-source compiler and test the resulting solution on synthetic as well as actual commercial IoT software bases, thereby demonstrating its advantages and drawbacks. -
Hiding Process Memory Via Anti-Forensic Techniques
DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible. -
The Ultimate C64 Overview Michael Steil, 25Th Chaos Communication Congress 2008
The Ultimate C64 Overview Michael Steil, http://www.pagetable.com/ 25th Chaos Communication Congress 2008 Retrocomputing is cool as never before. People play Look and Feel C64 games in emulators and listen to SID music, but few people know much about the C64 architecture A C64 only needs to be connected to power and a TV and its limitations, and what programming was like set (or monitor) to be fully functional. When turned back then. This paper attempts to give a comprehen- on, it shows a blue-on-blue theme with a startup mes- sive overview of the Commodore 64, including its in- sage and drops into a BASIC interpreter derived from ternals and quirks, making the point that classic Microsoft BASIC. In order to load and save BASIC computer systems aren't all that hard to understand - programs or use third party software, the C64 re- and that programmers today should be more aware of quires mass storage - either a “datasette” cassette the art that programming once used to be. tape drive or a disk drive like the 5.25" Commodore 1541. Commodore History Unless the user really wanted to interact with the BA- SIC interpreter, he would typically only use the BA- Commodore Business Machines was founded in 1962 SIC instructions LOAD, LIST and RUN in order to by Jack Tramiel. The company specialized on elec- access mass storage. LOAD"$",8 followed by LIST tronic calculators, and in 1976, Commodore bought shows the directory of the disk in the drive, and the chip manufacturer MOS Technology and decided LOAD"filename",8 followed by RUN would load and to have Chuck Peddle from MOS evolve their KIM-1 start a program. -
Z80 Bank-Switching Scheme An101
Z80 BANK-SWITCHING SCHEME AN101 1. INTRODUCTION 1. Scope: This Application Note gives a description of a circuit design allowing the classic Z80 microproces- sor to access expanded memory, beyond the 64K bytes made readily available by its 16 address lines, A0 through A15. 2. Z80 microprocessor: Though it has been over 20 years since the introduction of the Z80, this family of microprocessors still finds application in new designs. This is because the Z80 is still cost-effective for many 8-bit applications; because many users have a large library of tested code for the Z80; and because the parts are readily available from several manufacturers, easing supply concerns that apply to sole-sourced processors. 3. Applicable chips: This Application Note applies to the classic Z80 microprocessor. It can also be applied to the newer Z84C15, which comprises a Z80 CPU, a clock generator, four Z80 CTC channels, two Z80 SIO channels, DMA, chip select signals, and glue logic in a 100-pin quad flat pack. However this external bank-switching circuitry is not necessary for members of the Z80180 family, which have a built-in MMU (memory management unit) on-chip. 2. DESIGN GOALS 1. Program memory: We wanted to expand program memory space to 128K bytes for our application. We needed to support in-circuit reprogramming, so we chose the AMD 29F010 flash memory device. This +5 volt part does not require a +12 volt power supply for programming. After the flash chip is initially programmed at the factory with the bootstrap loader and the current application code, it can later be reprogrammed in the field over the RS-232 serial port. -
Context Switch Overheads for Linux on ARM Platforms
Context Switch Overheads for Linux on ARM Platforms Francis David [email protected] Jeffrey Carlyle [email protected] Roy Campbell [email protected] http://choices.cs.uiuc.edu Outline What is a Context Switch? ◦ Overheads ◦ Context switching in Linux Interrupt Handling Overheads ARM Experimentation Platform Context Switching ◦ Experiment Setup ◦ Results Interrupt Handling ◦ Experiment Setup ◦ Results What is a Context Switch? Storing current processor state and restoring another Mechanism used for multi-tasking User-Kernel transition is only a processor mode switch and is not a context switch Sources of Overhead Time spent in saving and restoring processor state Pollution of processor caches Switching between different processes ◦ Virtual memory maps need to be switched ◦ Synchronization of memory caches Paging Context Switching in Linux Context switch can be implemented in userspace or in kernelspace New 2.6 kernels use Native POSIX Threading Library (NPTL) NPTL uses one-to-one mapping of userspace threads to kernel threads Our experiments use kernel 2.6.20 Outline What is a Context Switch? ◦ Overheads ◦ Context switching in Linux Interrupt Handling Overheads ARM Experimentation Platform Context Switching ◦ Experiment Setup ◦ Results Interrupt Handling ◦ Experiment Setup ◦ Results Interrupt Handling Interruption of normal program flow Virtual memory maps not switched Also causes overheads ◦ Save and restore of processor state ◦ Perturbation of processor caches Outline What is a Context Switch? ◦ Overheads ◦ Context switching -
Lecture 4: September 13 4.1 Process State
CMPSCI 377 Operating Systems Fall 2012 Lecture 4: September 13 Lecturer: Prashant Shenoy TA: Sean Barker & Demetre Lavigne 4.1 Process State 4.1.1 Process A process is a dynamic instance of a computer program that is being sequentially executed by a computer system that has the ability to run several computer programs concurrently. A computer program itself is just a passive collection of instructions, while a process is the actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several windows of the same program typically means more than one process is being executed. The state of a process consists of - code for the running program (text segment), its static data, its heap and the heap pointer (HP) where dynamic data is kept, program counter (PC), stack and the stack pointer (SP), value of CPU registers, set of OS resources in use (list of open files etc.), and the current process execution state (new, ready, running etc.). Some state may be stored in registers, such as the program counter. 4.1.2 Process Execution States Processes go through various process states which determine how the process is handled by the operating system kernel. The specific implementations of these states vary in different operating systems, and the names of these states are not standardised, but the general high-level functionality is the same. When a process is first started/created, it is in new state. It needs to wait for the process scheduler (of the operating system) to set its status to "new" and load it into main memory from secondary storage device (such as a hard disk or a CD-ROM). -
IBM Power Systems Virtualization Operation Management for SAP Applications
Front cover IBM Power Systems Virtualization Operation Management for SAP Applications Dino Quintero Enrico Joedecke Katharina Probst Andreas Schauberer Redpaper IBM Redbooks IBM Power Systems Virtualization Operation Management for SAP Applications March 2020 REDP-5579-00 Note: Before using this information and the product it supports, read the information in “Notices” on page v. First Edition (March 2020) This edition applies to the following products: Red Hat Enterprise Linux 7.6 Red Hat Virtualization 4.2 SUSE Linux SLES 12 SP3 HMC V9 R1.920.0 Novalink 1.0.0.10 ipmitool V1.8.18 © Copyright International Business Machines Corporation 2020. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . .v Trademarks . vi Preface . vii Authors. vii Now you can become a published author, too! . viii Comments welcome. viii Stay connected to IBM Redbooks . ix Chapter 1. Introduction. 1 1.1 Preface . 2 Chapter 2. Server virtualization . 3 2.1 Introduction . 4 2.2 Server and hypervisor options . 4 2.2.1 Power Systems models that support PowerVM versus KVM . 4 2.2.2 Overview of POWER8 and POWER9 processor-based hardware models. 4 2.2.3 Comparison of PowerVM and KVM / RHV . 7 2.3 Hypervisors . 8 2.3.1 Introducing IBM PowerVM . 8 2.3.2 Kernel-based virtual machine introduction . 15 2.3.3 Resource overcommitment . 16 2.3.4 Red Hat Virtualization . 17 Chapter 3. IBM PowerVM management and operations . 19 3.1 Shared processor logical partitions . 20 3.1.1 Configuring a shared processor LPAR .