DOCSLIB.ORG

Wait-Free Code Patching of Multi-Threaded Processes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Wait-Free Code Patching of Multi-Threaded Processes From Global to Local Quiescence: Wait-Free Code Patching of Multi-Threaded Processes Florian Rommel, Christian Dietrich, Daniel Friesel, Marcel Köppen, Christoph Borchert, Michael Müller, Olaf Spincz !, Daniel "ohmann "eibniz %niversität (anno&er %niversität Osnabrüc! 2020-11-05 Dyna#ic Soft)are Updating ,pply updates during the run time *igh Availabilit- service quality must not decrease ./0ensive 'eboot e.g., applications with large run-time state Prime E0ample1 Operatin+ Systems → "in-0 Kernel (Ksplice, !Gra"t# 1serspace +0plications2 → DSU rarely used in practice 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel 2 / 22 /xa#ple1 OpenLD,. OpenLDAP server listener worker worker dispatch compute compute client client 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel 3 / 22 /xa#ple1 OpenLD,. do_work() void worker_thread() { void rwm_op_rollback( Operation *op, SlapReply *rs, rwm_op_state *ros ) { ... while (1) { op->o_tmpfree( ros->mapped_attrs, op->o_tmpmemctx ); filter_free_x( op, op->ors_filter, 1 ); wait_for_work(); op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); op->ors_attrs = ros->ors_attrs; do_work(); op->ors_filter = ros->ors_filter; } op->ors_filterstr = ros->ors_filterstr; } // quiescence point ... } "uggy if (patch_pending()) { barrier(); wait_for_patch(); void rwm_op_rollback( Operation *op, SlapReply *rs, rwm_op_state *ros ) { } ... if ( op->ors_filter != ros->ors_filter ) { } filter_free_x( op, op->ors_filter, 1 ); } op->ors_filter = ros->ors_filter; } void patcher_thread() { if ( op->ors_filterstr.bv_val != ros->ors_filterstr.bv_val ) { op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); while (1) { op->ors_filterstr = ros->ors_filterstr; } wait_for_patch_request(); ... patched set_patch_pending(); } barrier(); apply_patch(); reset_patch_pending(); Glo"al #uiescence: resume_workers(); All %or&ers must "e in } the "arrier "efore patching } 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel 4 / 22 Global 3-iescence 4he to-be-patched code is not active in any threa* 150 ] Pro"lems s / 1 [ s 100 ()$ Long Calculations e s n o p 50 (*$ +,O Operations e R (-$ +nter-Thread Dependencies 0 0.0 0.2 0.4 0.6 0.8 1.0 Response Time relative to Patch Request [s] 150 ] s m [ y c 100 n e t a L . 50 x a M 0 0.0 0.2 0.4 0.6 0.8 1.0 Response Time relative to Patch Request [s] 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel ) / 22 Global 3-iescence → MariaDB1 Transaction Loc!s Pro"lems ()$ Long Calculations tx_lock() barrier() (*$ +,O Operations Thread ) (-$ +nter-Thread Dependencies tx_lock() Deadloc& Thread * time 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel 5 / 22 Kernelspace Ksplice1 Probe #or quiescence instead of 8aiting in a barrier → .atch #ay never get applied !2raft, DynAMOS: 9eep patched and unpatched #unctions in parallel Decide on per-thread-basis which version to use Global quiescence → local quiescence → .roblems: kernel-speci5c, perfor#ance penalt 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel 6 / 22 Local Quiescence Basic Idea: Patching threads in*ependently from each other7 Wait-Free Code Patching via Address-Space !enerations O. extension for run-time modi0cation in multi-threaded processes ,S generations: Multiple views of an address-space 4hread-local q-iescence 4hread-by-thread migration bet)een AS generations → +mplementation in the Linux 1ernel 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel : / 22 2020-(1-0) Max. Latency [ms] Reponses [1/s] Quiescence Local 100 100 150 150 100 150 50 50 50 0 0 0 OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel Florian — rocesses $ulti-%!readed o# atchin" Code Wait-Free Quiescence: Local to Global From '20 OSDI 0.0 0.0 0.0 Response Time relative to Patch Request [s] Request to Patch [s] relative Time Request to Patch Response relative Time Response [s] Request to Patch relative Time Response 0.2 0.2 0.2 0.4 0.4 0.4 0.6 0.6 0.6 0.8 0.8 0.8 1.0 1.0 1.0 → + n 2 t e o r - m Local Local Quiescence Global Quiescence T o h r r e e a d d e a D d e l p o e c n & d s 3 e n c ; i / e 22 s ,**ress-Space 2enerations wf_create() ad*ress Generation 0 Generation 1 space te0t te0t patche* wf_pin() Cop--On-WriteShared $a00ing $a00ing data data 9 Shared $a00ing 9 stac! stac! 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel (0 / 22 ,**ress-Space 2enerations wf_delete() wf_create() ad*ress Generation 0 Generation 1 space te0t te0t patche* wf_pin() Cop--On-Write $a00ing data data 9 Shared $a00ing 9 stac! stac! threads wf_migrate() th2 th1 th3 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel (( / 22 /xa#ple1 OpenLD,. do_work() void worker_thread() { void rwm_op_rollback( Operation *op, SlapReply *rs, rwm_op_state *ros ) { ... while (1) { op->o_tmpfree( ros->mapped_attrs, op->o_tmpmemctx ); filter_free_x( op, op->ors_filter, 1 ); wait_for_work(); op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); op->ors_attrs = ros->ors_attrs; do_work(); op->ors_filter = ros->ors_filter; op->ors_filterstr = ros->ors_filterstr; ... // quiescence point } "uggy if (patch_pendingmigration_pending()) {()) { barrierwf_migrate();(); } wait_for_patch(); void rwm_op_rollback( Operation *op, SlapReply *rs, rwm_op_state *ros ) { } ... if ( op->ors_filter != ros->ors_filter ) { } filter_free_x( op, op->ors_filter, 1 ); } op->ors_filter = ros->ors_filter; } void patcher_thread() { if ( op->ors_filterstr.bv_val != ros->ors_filterstr.bv_val ) { op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); while (1) { op->ors_filterstr = ros->ors_filterstr; } wait_for_patch_request(); ... patched set_patch_pendingwf_create(); (); } barrierwf_migrate();(); apply_patch(); reset_patch_pendingset_migration_pending();(); }resume_workers(); }} } 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel 12 / 22 6#ple#entation in the Linux Kernel wf_create Memor' Map 4MM5 Cloned MM %f_create Clones the #e#or #ap :MM; = ,S generation COW COW text text li!e fork() $-t )ithout CO= wf_pin data & bss data & bss Howe&er, pinne* #appings use CO= heap heap %f_migrate Changes the thread’s MM pointer file mapping file mapping Conte0t s)itch file mapping file mapping stack stack Thread 1 *MM Thread 2 *MM Thread 3 *MM 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel (3 / 22 6#ple#entation in the Linux Kernel wf_create Memor'Master MM Map 4MM5 Cloned MM %f_create Clones the #e#or #ap :MM; = ,S generation COW COW text text li!e fork() $-t )ithout CO= wf_pin data & bss data & bss Howe&er, pinned #appin+s use COW heap heap heap heap %f_migrate Changes the thread’s MM pointer Page Fault Page Fault Conte0t s)itch file mapping file mapping Mapping Changes stack stack S nchronize* on all MMs Master MM1 "az page initialization, "oc!ing pro0 Thread 1 *MM Thread 2 *MM Thread 3 *MM 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel (4 / 22 /&aluation: .atches De$ian 1070 pac!a+es and De$ian patches :e0cept MariaDB; OpenLDAP Apache Memcached Samba MariaDB 2ode.8s .atches :CVE) 13 :2) 10 :10) 1 :1) 2 :2) 74 :26; 4 :0) Restrict to code-only patches :6< =::<> te0t-onl 9 :2) 7 :A; 1 :1) 2 :2) 67 :2B; 4 :0) !enerate patches via Kpatch 3;< =46<> !patch>a$le 9 :2) 7 :A; 1 :1) 2 :2; 16 :5) 0 :0) 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel () / 22 /&aluation: Ee8uest "atencies 105 106 P99.5 (=143.52ms) P99.5 (=601.00ms) P99.5 (=855.90ms) Global Quiescence Global Quiescence Global Quiescence 3 10 4 103 10 s s s t t t s s s e e e 2 u 1 u 101 u 10 q 10 q q e e e R R R f f f o 5 o o 6 10 10 r P99.5 (=9.56ms) r P99.5 (=541.00ms) r P99.5 (=32.38ms) e e e b Local Quiescence b Local Quiescence b Local Quiescence m m 3 m 4 u u 10 u 103 10 N N N 2 1 10 101 10 0 20 40 60 80 100 120 140 0 200 400 600 800 1000 1200 1400 0 200 400 600 800 1000 OpenLDAP: Histogram of Request Latency [ms] Apache: Histogram of Request Latency [ms] Memcached: Histogram of Request Latency [ms] 107 P99.5 (=760.68ms) 105 P99.5 (=323.62ms) P99.5 (=236.08ms) 5 Global Quiescence Global Quiescence Global Quiescence 10 103 103 s s s t t 3 t s s 10 s e e e u u 1 u 101 q q 1 10 q e 10 e e R R R f f f o o o 7 r r 10 P99.5 (=55.69ms) 5 P99.5 (=7.84ms) r P99.5 (=243.15ms) e e 10 e b Local Quiescence b Local Quiescence b Local Quiescence m 105 m m 3 u u u 10 N N 3 10 N 103 1 1 10 101 10 0 500 1000 1500 2000 2500 3000 3500 0 200 400 600 800 1000 0 250 500 750 1000 1250 1500 1750 Samba: Histogram of File I/O Latency [ms] MariaDB: Histogram of Request Latency [ms] Node.js: Histogram of Request Latency [ms] 2020-(1-0) OSDI '20 From Global to Local Quiescence: Wait-Free Code atchin" o# $ulti-%!readed rocesses — Florian 'ommel (5 / 22 /&aluation: Ee8uest "atencies 105 P99.5 (=143.52ms) Global Quiescence 103
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.
    [Show full text]
  • 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
    [Show full text]
  • Fast and Scalable VMM Live Upgrade in Large Cloud Infrastructure
    Fast and Scalable VMM Live Upgrade in Large Cloud Infrastructure Xiantao Zhang Xiao Zheng Zhi Wang Alibaba Group Alibaba Group Florida State University [email protected] [email protected] [email protected] Qi Li Junkang Fu Yang Zhang Tsinghua University Alibaba Group Alibaba Group [email protected] [email protected] [email protected] Yibin Shen Alibaba Group [email protected] Abstract hand over passthrough devices to the new KVM instance High availability is the most important and challenging prob- without losing any ongoing (DMA) operations. Our evalua- lem for cloud providers. However, virtual machine mon- tion shows that Orthus can reduce the total migration time itor (VMM), a crucial component of the cloud infrastruc- and downtime by more than 99% and 90%, respectively. We ture, has to be frequently updated and restarted to add secu- have deployed Orthus in one of the largest cloud infrastruc- rity patches and new features, undermining high availabil- tures for a long time. It has become the most effective and ity. There are two existing live update methods to improve indispensable tool in our daily maintenance of hundreds of the cloud availability: kernel live patching and Virtual Ma- thousands of servers and millions of VMs. chine (VM) live migration. However, they both have serious CCS Concepts • Security and privacy → Virtualization drawbacks that impair their usefulness in the large cloud and security; • Computer systems organization → Avail- infrastructure: kernel live patching cannot handle complex ability. changes (e.g., changes to persistent data structures); and VM live migration may incur unacceptably long delays when Keywords virtualization; live upgrade; cloud infrastructure migrating millions of VMs in the whole cloud, for example, ACM Reference Format: to deploy urgent security patches.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • Live Kernel Patching Using Kgraft
    SUSE Linux Enterprise Server 12 SP4 Live Kernel Patching Using kGraft SUSE Linux Enterprise Server 12 SP4 This document describes the basic principles of the kGraft live patching technology and provides usage guidelines for the SLE Live Patching service. kGraft is a live patching technology for runtime patching of the Linux kernel, without stopping the kernel. This maximizes system uptime, and thus system availability, which is important for mission-critical systems. By allowing dynamic patching of the kernel, the technology also encourages users to install critical security updates without deferring them to a scheduled downtime. A kGraft patch is a kernel module, intended for replacing whole functions in the kernel. kGraft primarily oers in-kernel infrastructure for integration of the patched code with base kernel code at runtime. SLE Live Patching is a service provided on top of regular SUSE Linux Enterprise Server maintenance. kGraft patches distributed through SLE Live Patching supplement regular SLES maintenance updates. Common update stack and procedures can be used for SLE Live Patching deployment. Publication Date: 09/24/2021 Contents 1 Advantages of kGraft 3 2 Low-level Function of kGraft 3 1 Live Kernel Patching Using kGraft 3 Installing kGraft Patches 4 4 Patch Lifecycle 6 5 Removing a kGraft Patch 6 6 Stuck Kernel Execution Threads 6 7 The kgr Tool 7 8 Scope of kGraft Technology 7 9 Scope of SLE Live Patching 8 10 Interaction with the Support Processes 8 11 GNU Free Documentation License 8 2 Live Kernel Patching Using kGraft 1 Advantages of kGraft Live kernel patching using kGraft is especially useful for quick response in emergencies (when serious vulnerabilities are known and should be xed when possible or there are serious system stability issues with a known x).
    [Show full text]
  • 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
    [Show full text]
  • 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).
    [Show full text]
  • 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 .
    [Show full text]
  • Lecture 6: September 20 6.1 Threads
    CMPSCI 377 Operating Systems Fall 2012 Lecture 6: September 20 Lecturer: Prashant Shenoy TA: Sean Barker & Demetre Lavigne 6.1 Threads A thread is a sequential execution stream within a process. This means that a single process may be broken up into multiple threads. Each thread has its own Program Counter, registers, and stack, but they all share the same address space within the process. The primary benefit of such an approach is that a process can be split up into many threads of control, allowing for concurrency since some parts of the process to make progress while others are busy. Sharing an address space within a process allows for simpler coordination than message passing or shared memory. Threads can also be used to modularize a process { a process like a web browser may create one thread for each browsing tab, or create threads to run external plugins. 6.1.1 Processes vs threads One might argue that in general processes are more flexible than threads. For example, processes are controlled independently by the OS, meaning that if one crashes it will not affect other processes. However, processes require explicit communication using either message passing or shared memory which may add overhead since it requires support from the OS kernel. Using threads within a process allows them all to share the same address space, simplifying communication between threads. However, threads have their own problems: because they communicate through shared memory they must run on same machine and care must be taken to create thread-safe code that functions correctly despite multiple threads acting on the same set of shared data.
    [Show full text]
  • Mitigating the Performance-Efficiency Tradeoff in Resilient Memory Disaggregation
    Mitigating the Performance-Efficiency Tradeoff in Resilient Memory Disaggregation Youngmoon Lee∗, Hasan Al Maruf∗, Mosharaf Chowdhury∗, Asaf Cidonx, Kang G. Shin∗ University of Michigan∗ Columbia Universityx ABSTRACT State-of-the-art solutions take three primary approaches: (i) local We present the design and implementation of a low-latency, low- disk backup [36, 66], (ii) remote in-memory replication [31, 50], and overhead, and highly available resilient disaggregated cluster mem- (iii) remote in-memory erasure coding [61, 64, 70, 73] and compres- ory. Our proposed framework can access erasure-coded remote sion [45]. Unfortunately, they suffer from some combinations of memory within a single-digit `s read/write latency, significantly the following problems. improving the performance-efficiency tradeoff over the state-of- High latency: The first approach has no additional memory the-art – it performs similar to in-memory replication with 1.6× overhead, but the access latency is intolerably high in the presence lower memory overhead. We also propose a novel coding group of any of the aforementioned failure scenarios. The systems that placement algorithm for erasure-coded data, that provides load bal- take the third approach do not meet the single-digit `s latency ancing while reducing the probability of data loss under correlated requirement of disaggregated cluster memory even when paired failures by an order of magnitude. with RDMA (Figure 1). High cost: While the second approach has low latency, it dou- bles memory consumption as well as network bandwidth require- ments. The first and second approaches represent the two extreme 1 INTRODUCTION points in the performance-vs-efficiency tradeoff space for resilient To address the increasing memory pressure in datacenters, two cluster memory (Figure 1).
    [Show full text]
  • Think ALL Distros Offer the Best Linux Devsecops Environment?
    Marc Staimer, Dragon Slayor Consulting WHITE PAPER Think All Distros Offer the Best Linux DevSecOps What You’re Not Being Told About Environment? Database as a Service (DBaaS) Think Again! WHITE PAPER • Think Again! Think All Distros Provide the Best Linux DevSecOps Environment? Think Again! Introduction DevOps is changing. Developing code with after the fact bolt-on security is dangerously flawed. When that bolt-on fails to correct exploitable code vulnerabilities, it puts the entire organization at risk. Security has been generally an afterthought for many doing DevOps. It was often assumed the IT organization’s systemic multiple layers of security measures and appliances would protect any new code from malware or breaches. And besides, developing code with security built in, adds tasks and steps to development and testing time. More tasks and steps delay time-to-market. Multi-tenant clouds have radically changed the market. Any vulnerability in a world with increasing cyber-attacks, can put millions of user’s data at risk. Those legacy DevOps attitudes are unsound. They are potentially quite costly in the current environment. Consider that nearly every developed and most developing countries have enacted laws and regulation protecting personally identifiable information or PII1. PII is incredibly valuable to cybercriminals. Stealing PII enables them to commit many cybercrimes including the cybertheft of identities, finances, intellectual property, admin privileges, and much more. PII can also be sold on the web. Those PII laws and regulations are meant to force IT organizations to protect PII. Non-compliance of these laws and regulations often carry punitive financial penalties.
    [Show full text]