Operating Systems and Resource Reservations

Total Page:16

File Type:pdf, Size:1020Kb

Operating Systems and Resource Reservations Operating Systems And Resource Reservations Antonio Mancina ReTiS Lab Scuola Superiore S.Anna, Pisa Ph.D. Thesis 03 April 2009 Tutor: Giuseppe Lipari ............................................... Supervisor: Tommaso Cucinotta ............................................... I would like to dedicate this thesis to several people. First of all, to my girlfriend, Monica, who (almost) always supports my decisions and helps me a lot, even with my work, if and when possible. Secondly, to my family which patiently put up with me in every situation (but I know it’s an easy task, I’m a wonderful son and a really nice brother!). Finally, to every single person belonging to the ReTiS Lab (and, recently, to the CEIIC building in general) thanks to which I’ve spent the most pleasant years of my life. Thank you all, folks! Acknowledgements I would like to acknowledge several people, hoping not to forget any- one. First of all, my tutor, Giuseppe Lipari who, although being pressed by several obligations from his work, always found sufficient time to dedicate to me. Secondly, the ReTiS OS group, made by Luca Marzario, Michael Trimarchi, Tommaso Cucinotta, Fabio Checconi and, recently, Dario Faggioli that helped me a lot in every situation (not necessarily inherent to my research); due to his very recent ef- forts to be accepted (and even appreciated) by this group, I’ll list here Marko Bertogna, who recently got married: my best wishes, Marko and Lidia! Finally, the group of friends and special people I met during the years I spent here: Luigi Palopoli, Giorgio Buttazzo, Marco Di Natale, Paolo Ancilotti, Mara Gandolfo, Enrico Bini, Paolo Gai, Giacomo Guidi, Davide Pagnin, Paolo Valente, Michele Cirinei, Igor Barsanti, Gabriele Cecchetti, Annalina Ruscelli, Luca Santinelli, Mangesh Chitnis, Yifan Wu, Paolo Pagano, Claudio Scordino, Nicola Serreli. I met many other people during the last five years, and I can say, as a bullet-proof concept, that the Real-Time System Lab is one of the best work-places which I have ever been part of. Abstract Nowadays, an ever increasing interest from the industrial world in real-time scheduling capable operating systems is driving many de- velopment efforts in the context of general purpose operating systems towards the introduction of specific mechanisms able to provide the system user with some real-time capabilities. The recent literature de- scribes many different approaches and so lutions to this problam and this leads to a wide variety of mechanisms, each with its drawbacks and its advantages. In this work the existing state of the art inherent to the application of real-time experiences and principles within modern operating systems is going to be analyzed. Contributions of this thesis may be listed as follows: • an implementation of an Earliest Deadline First scheduler along with an algorithm for resource sharing in the context of a modern monolithic kernel based operating system; • an implementation of Resource Reservation algorithms within a modern microkernel based operating system; • the design and a possible implementation of a taxonomy to de- scribe the class of resource reservation algorithms and to help the researcher to conceive and implement new scheduling algorithms belonging to this class. In the author’s opinion the last point is a fundamental contribute to start enriching the current state of the art with a better and more unified way to face real-time issues in the context of general purpose operating systems. Contents Nomenclature viii 1 Introduction 1 2 Operating Systems and Real-Time 5 2.1TerminologyandgeneralOSconcepts................ 6 2.1.1 Process,threadsandtaskscheduling............ 6 2.1.2 Inter-ProcessCommunication................ 8 2.1.3 ResourcesSharing....................... 10 2.1.4 Interruptsandsystemcalls.................. 11 2.2Standardprogrammingandcommunicationinterfaces....... 13 2.2.1 ThePortableOperatingSystemInterface.......... 13 2.2.2 Osek/VDX.......................... 13 2.2.3 ARINC............................ 14 2.2.4 ITRON............................ 14 2.3Real-TimeScheduling......................... 14 2.3.1 ClassicTheory........................ 16 2.3.2 QualityofService....................... 18 2.4BriefanalysisofexistingOperatingSystems............ 20 2.4.1 Generalpurposeoperatingsystems............. 20 2.4.2 OSforembeddedplatforms................. 23 2.4.3 Real-timeoperatingsystems................. 24 2.5Conclusions.............................. 27 iv CONTENTS 3 Resource Reservations 28 3.1AbriefintroductiontoResourceReservations........... 28 3.1.1 Theneedfortemporalprotection.............. 29 3.1.2 Ageneraldefinition...................... 30 3.1.2.1 Generalproperties................. 31 3.1.3 OtherModels......................... 31 3.1.3.1 The α/Δmodel................... 32 3.1.3.2 TheVirtualTimemodel.............. 33 3.2RRESalgorithmssurvey....................... 34 3.2.1 TheConstantBandwidthServer............... 34 3.2.2 GreedyReclamationofUnusedBandwidth......... 35 3.2.3 TheIdle-timeReclaimingImprovedServer......... 37 3.2.4 TheCApacitySHaringServer................ 39 3.3Pickinguptherightalgorithm.................... 41 3.3.1 Sparebandwidth....................... 42 3.3.2 Applyingthemodels..................... 44 3.3.3 Drawingconclusions..................... 45 3.4Finalremarks............................. 46 4 Implementing Resource Reservations in modern Operating Sys- tems 47 4.1OSReal-Timecompliance...................... 47 4.1.1 Operatingsystemsconceptoftime............. 47 4.1.2 Real-timepriorities...................... 48 4.2Linux................................. 48 4.2.1 Linuxschedulingframework................. 49 4.2.1.1 ModularSchedulerFramework.......... 49 4.2.1.2 LinuxandGroupScheduling........... 50 4.2.2 AlgorithmDescription.................... 50 4.2.2.1 CriticalSections.................. 51 4.2.2.2 AdmissionControl................. 53 4.2.2.3 ExportedInterface................. 56 4.2.2.4 Implementationdetails............... 58 v CONTENTS 4.3Experimentalevaluations....................... 58 4.4 MINIX 3 ................................ 59 4.4.1 OSgeneraldescription.................... 61 4.4.2 ResourceReservations.................... 62 4.4.3 RelatedWork......................... 63 4.4.3.1 MonolithicOperatingSystemStructure..... 63 4.4.3.2 MultiserverOperatingSystemStructure..... 64 4.4.4 Designandimplementation................. 65 4.4.4.1 High-levelDesignOverview............ 65 4.4.4.2 ImplementationoftheRRESManager...... 66 4.4.4.3 KernelandSchedulerModifications........ 69 4.4.4.4 CPUTimeAccounting............... 71 4.4.5 RREScasestudy....................... 72 4.4.6 Experimentalevaluation................... 75 4.4.6.1 TimingMeasurements............... 75 4.4.6.2 ImpactonKernelandUser-SpaceCode..... 76 4.4.6.3 RRESTracerandSimulations........... 76 4.4.7 Conclusionsandfuturework................. 78 4.5Conclusions.............................. 79 5 The Generic Resource Reservation Framework 81 5.1StateDiagram............................. 81 5.1.1 MappingsinGRRF...................... 85 5.1.1.1 GRRF:CBS.................... 85 5.1.1.2 GRRF:IRIS.................... 87 5.1.1.3 GRRF:GRUB................... 88 5.1.1.4 GRRF:CASH................... 88 5.2IMPLEMENTATION......................... 89 5.2.1 MINIX 3 ............................ 89 5.3Conclusionsandfuturework..................... 93 6 Conclusions 95 References 102 vi List of Figures 1.1Typicalembedded-platformsdevelopmentcycle.......... 2 2.1Processstatesdiagram........................ 7 2.2Communicationthroughpipes.................... 8 2.3Communicationthroughsharedmemory.............. 9 2.4Interruptssystemimplementation.................. 12 2.5 A graphical representation of the important task parameters. 15 2.6Sampletasksetusedinthissection................. 16 2.7 The scheduling sequence obtained from a Rate Monotonic sched- uler .................................. 17 2.8 The scheduling sequence obtained from an Earliest Deadline First scheduler ............................... 18 2.9Monolithickernelstructure...................... 21 2.10Minix3architecture(microkernel-like)............... 22 3.1Sampletasksetusedinthissection................. 29 3.2 The so-called domino effect may happen in case of task overruns 30 3.3 A graphical representation of the Δk parameter.......... 32 3.4TheAlpha-Deltaservicecurve ................... 33 3.5 A misbehaving task is made harmless within a CBS scheduling environment.............................. 35 3.6Thedeadlineagingproblem..................... 37 3.7 The CBS might provide a different service then what expected . 37 3.8ThisishowIRISsolvesthedeadlineagingproblem........ 39 3.9IRISprovidesexactlytheservicerequested............. 39 vii LIST OF FIGURES 3.10ThemodifiedtasksetfortheCASHexample............ 40 3.11ThesetofVirtualResourcesservingtheprevioustaskset..... 40 3.12TheresultingCASHschedule.................... 41 3.13MainfeaturesofsomeimportantRRESalgorithms......... 43 4.1LightTasks,BigPeriodSpan..................... 59 4.2 hk SpanforLightTasks,BigPeriodSpan.............. 60 4.3 High-level architecture over the resource reservation framework. Messages exchanged between the RRES helper utilities, RRES managerandkernelareshown.................... 67 4.4MessagesexchangedwithintheRRESframework. ........ 68 4.5 RRES-enhanced MINIX 3 scheduling queue data structure. Two new queues at the two highest priority levels were added for the RRESmanagerandthecurrentreal-timetask............ 70 4.6 Schedule of the case study in milliseconds. ........... 74 4.7
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]
  • Real-Time Scheduling: from Hard to Soft Real-Time Systems
    Real-Time scheduling: from hard to soft real-time systems Giuseppe Lipari Luigi Palopoli Université de Lille 1 Università di Trento [email protected] [email protected] December 8, 2015 Abstract Real-time systems are traditionally classified into hard real-time and soft real-time: in the first category we have safety critical real-time sys- tems where missing a deadline can have catastrophic consequences, whereas in the second class we find systems for which we need to optimise the Quality of service provided to the user. However, the frontier between these two classes is thinner than one may think, and many systems that were considered as hard real-time in the past should now be reconsidered under a different light. In this paper we shall first recall the fundamental notion of time- predictability and criticality, in order to understand where the real-time deadlines that we use in our theoretical models come from. We shall then introduce the model of a soft real-time system and present one popular method for scheduling hard and soft real-time tasks, the resource reserva- tion framework. Finally, we shall show how resource reservation techniques can be suc- cessfully applied to the design of classical control systems, thus adding robustness to the system and increasing resource utilisation and perfor- mance. 1 Introduction arXiv:1512.01978v1 [cs.OS] 7 Dec 2015 Real-time systems are computational systems whose correctness depends not only on the correctness of the produced results, but also on the time at which they are produced. They must interact with their external environment in a timely manner: for example, real-time systems that control physical plants (digital control systems, or the so-called cyber-physical systems) must perform their computation and produce their results at the typical timing rates of the physical environment, and within a bounded delay.
    [Show full text]
  • Validated Products List, 1995 No. 3: Programming Languages, Database
    NISTIR 5693 (Supersedes NISTIR 5629) VALIDATED PRODUCTS LIST Volume 1 1995 No. 3 Programming Languages Database Language SQL Graphics POSIX Computer Security Judy B. Kailey Product Data - IGES Editor U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Computer Systems Laboratory Software Standards Validation Group Gaithersburg, MD 20899 July 1995 QC 100 NIST .056 NO. 5693 1995 NISTIR 5693 (Supersedes NISTIR 5629) VALIDATED PRODUCTS LIST Volume 1 1995 No. 3 Programming Languages Database Language SQL Graphics POSIX Computer Security Judy B. Kailey Product Data - IGES Editor U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Computer Systems Laboratory Software Standards Validation Group Gaithersburg, MD 20899 July 1995 (Supersedes April 1995 issue) U.S. DEPARTMENT OF COMMERCE Ronald H. Brown, Secretary TECHNOLOGY ADMINISTRATION Mary L. Good, Under Secretary for Technology NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Arati Prabhakar, Director FOREWORD The Validated Products List (VPL) identifies information technology products that have been tested for conformance to Federal Information Processing Standards (FIPS) in accordance with Computer Systems Laboratory (CSL) conformance testing procedures, and have a current validation certificate or registered test report. The VPL also contains information about the organizations, test methods and procedures that support the validation programs for the FIPS identified in this document. The VPL includes computer language processors for programming languages COBOL, Fortran, Ada, Pascal, C, M[UMPS], and database language SQL; computer graphic implementations for GKS, COM, PHIGS, and Raster Graphics; operating system implementations for POSIX; Open Systems Interconnection implementations; and computer security implementations for DES, MAC and Key Management.
    [Show full text]
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra
    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
    [Show full text]
  • Building Performance Measurement Tools for the MINIX 3 Operating System
    Building Performance Measurement Tools for the MINIX 3 Operating System Rogier Meurs August 2006 Contents 1 INTRODUCTION 1 1.1 Measuring Performance 1 1.2 MINIX 3 2 2 STATISTICAL PROFILING 3 2.1 Introduction 3 2.2 In Search of a Timer 3 2.2.1 i8259 Timers 3 2.2.2 CMOS Real-Time Clock 3 2.3 High-level Description 4 2.4 Work Done in User-Space 5 2.4.1 The SPROFILE System Call 5 2.5 Work Done in Kernel-Space 5 2.5.1 The SPROF Kernel Call 5 2.5.2 Profiling using the CMOS Timer Interrupt 6 2.6 Work Done at the Application Level 7 2.6.1 Control Tool: profile 7 2.6.2 Analyzing Tool: sprofalyze.pl 7 2.7 What Can and What Cannot be Profiled 8 2.8 Profiling Results 8 2.8.1 High Scoring IPC Functions 8 2.8.2 Interrupt Delay 9 2.8.3 Profiling Runs on Simulator and Other CPU Models 12 2.9 Side-effect of Using the CMOS Clock 12 3 CALL PROFILING 13 3.1 Introduction 13 3.1.1 Compiler-supported Call Profiling 13 3.1.2 Call Paths, Call and Cycle Attribution 13 3.2 High-level Description 14 3.3 Work Done in User-Space 15 3.3.1 The CPROFILE System Call 15 3.4 Work Done in Kernel-Space 16 3.4.1 The PROFBUF and CPROF Kernel Calls 16 3.5 Work Done in Libraries 17 3.5.1 Profiling Using Library Functions 17 3.5.2 The Procentry Library Function 17 3.5.3 The Procexit Library Function 20 3.5.4 The Call Path String 22 3.5.5 Testing Overhead Elimination 23 3.6 Profiling Kernel-Space/User-Space Processes 24 3.6.1 Differences in Announcing and Table Sizes 24 3.6.2 Kernel-Space Issue: Reentrancy 26 3.6.3 Kernel-Space Issue: The Call Path 26 3.7 Work Done at the Application
    [Show full text]
  • Aquosa-Adaptive Quality of Service Architecture
    SOFTWARE—PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2009; 39:1–31 Published online 1 April 2008 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spe.883 AQuoSA—adaptive quality of service architecture L. Palopoli1,T.Cucinotta2,∗,†, L. Marzario2 and G. Lipari2 1DIT, University of Trento, Italy 2ReTiS Laboratory, Scuola Superiore Sant’Anna, Via Moruzzi, 1, 56124 Pisa, Italy SUMMARY This paper presents an architecture for quality of service (QoS) control of time-sensitive applications in multi-programmed embedded systems. In such systems, tasks must receive appropriate timeliness guarantees from the operating system independently from one another; otherwise, the QoS experienced by the users may decrease. Moreover, fluctuations in time of the workloads make a static partitioning of the central processing unit (CPU) that is neither appropriate nor convenient, whereas an adaptive allocation based on an on-line monitoring of the application behaviour leads to an optimum design. By combining a resource reservation scheduler and a feedback-based mechanism, we allow applications to meet their QoS requirements with the minimum possible impact on CPU occupation. We implemented the framework in AQuoSA (Adaptive Quality of Service Architecture (AQuoSA). http://aquosa.sourceforge.net), a software architecture that runs on top of the Linux kernel. We provide extensive experimental validation of our results and offer an evaluation of the introduced overhead, which is perfectly sustainable in the class of addressed applications. Copyright © 2008 John Wiley & Sons, Ltd. Received 29 June 2007; Revised 28 January 2008; Accepted 1 February 2008 KEY WORDS: resource reservations; adaptive QoS control; soft real time; embedded systems; operating systems 1.
    [Show full text]
  • RTI Data Distribution Service Platform Notes
    RTI Data Distribution Service The Real-Time Publish-Subscribe Middleware Platform Notes Version 4.5c © 2004-2010 Real-Time Innovations, Inc. All rights reserved. Printed in U.S.A. First printing. June 2010. Trademarks Real-Time Innovations and RTI are registered trademarks of Real-Time Innovations, Inc. All other trademarks used in this document are the property of their respective owners. Copy and Use Restrictions No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form (including electronic, mechanical, photocopy, and facsimile) without the prior written permission of Real- Time Innovations, Inc. The software described in this document is furnished under and subject to the RTI software license agreement. The software may be used or copied only under the terms of the license agreement. Technical Support Real-Time Innovations, Inc. 385 Moffett Park Drive Sunnyvale, CA 94089 Phone: (408) 990-7444 Email: [email protected] Website: http://www.rti.com/support Contents 1 Supported Platforms.........................................................................................................................1 2 AIX Platforms.....................................................................................................................................3 2.1 Changing Thread Priority.......................................................................................................3 2.2 Multicast Support ....................................................................................................................3
    [Show full text]
  • Execution Time Monitoring in Linux∗
    Execution Time Monitoring in Linux∗ Mikael Asberg,˚ Thomas Nolte Clara M. Otero Perez´ Shinpei Kato MRTC/Malardalen¨ University NXP Semiconductors/Research The University of Tokyo P.O. Box 883, SE-721 23, High Tech Campus 32 (102) 7-3-1 Hongo, Bunkyo-ku, Vaster¨ as,˚ Sweden 5656 AE Eindhoven, Holland Tokyo 113-8656, Japan [email protected] [email protected] [email protected] Abstract estimate and the current system state. For example, if only one component is active, then it can run at the maximum This paper presents an implementation of an Execution QoS using 75% of a given resource. However, if a sec- Time Monitor (ETM) which can be applied in a resource ond identical component is started, then both components management framework, such as the one proposed in the will have to adapt to a lower QoS where each of them uses Open Media Platform (OMP) [4]. OMP is a European 50% of the same resource. project which aims at creating an open, flexible and re- In media processing systems, the load is very dynamic source efficient software architecture for mobile devices and the worst case is often unknown (unpredictable) or too such as cell phones and handsets. One of its goals is to high to do worst case resource allocation (since it will im- open up the possibility for software portability and fast ply wasting resources). The initial resource estimate pro- integration of applications, in order to decrease develop- vided by the component is used to create the initial allo- ment costs.
    [Show full text]
  • Isolation, Resource Management, and Sharing in Java
    Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java Godmar Back, Wilson C. Hsieh, Jay Lepreau School of Computing University of Utah Abstract many environments for executing untrusted code: for example, applets, servlets, active packets [41], database Single-language runtime systems, in the form of Java queries [15], and kernel extensions [6]. Current systems virtual machines, are widely deployed platforms for ex- (such as Java) provide memory protection through the ecuting untrusted mobile code. These runtimes pro- enforcement of type safety and secure system services vide some of the features that operating systems pro- through a number of mechanisms, including namespace vide: inter-application memory protection and basic sys- and access control. Unfortunately, malicious or buggy tem services. They do not, however, provide the ability applications can deny service to other applications. For to isolate applications from each other, or limit their re- example, a Java applet can generate excessive amounts source consumption. This paper describes KaffeOS, a of garbage and cause a Web browser to spend all of its Java runtime system that provides these features. The time collecting it. KaffeOS architecture takes many lessons from operating To support the execution of untrusted code, type-safe system design, such as the use of a user/kernel bound- language runtimes need to provide a mechanism to iso- ary, and employs garbage collection techniques, such as late and manage the resources of applications, analogous write barriers. to that provided by operating systems. Although other re- The KaffeOS architecture supports the OS abstraction source management abstractions exist [4], the classic OS of a process in a Java virtual machine.
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Libresource - Getting System Resource Information with Standard Apis Tuesday, 13 November 2018 14:55 (15 Minutes)
    Linux Plumbers Conference 2018 Contribution ID: 255 Type: not specified libresource - Getting system resource information with standard APIs Tuesday, 13 November 2018 14:55 (15 minutes) System resource information, like memory, network and device statistics, are crucial for system administrators to understand the inner workings of their systems, and are increasingly being used by applications to fine tune performance in different environments. Getting system resource information on Linux is not a straightforward affair. The best way is tocollectthe information from procfs or sysfs, but getting such information from procfs or sysfs presents many challenges. Each time an application wants to get a system resource information, it has to open a file, read the content and then parse the content to get actual information. If application is running in a container then even reading from procfs directly may give information about resources on whole system instead of just the container. Libresource tries to fix few of these problems by providing a standard library with set of APIs through which we can get system resource information e.g. memory, CPU, stat, networking, security related information. Libresource provides/may provide following benefits: • Virtualization: In cases where application is running in a virtualized environment using cgroup or namespaces, reading from /proc and /sys file-systems might not give correct information as these are not cgroup aware. Library API will take care of this e.g. if a process is running in a cgroup then library should provide information which is local to that cgroup. • Ease of use: Currently applications needs to read this info mostly from /proc and /sys file-systems.
    [Show full text]
  • Introduction to Performance Management
    C HAPTER 1 Introduction to Performance Management Application developers and system administrators face similar challenges in managing the performance of a computer system. Performance manage- ment starts with application design and development and migrates to administration and tuning of the deployed production system or systems. It is necessary to keep performance in mind at all stages in the development and deployment of a system and application. There is a definite over- lap in the responsibilities of the developer and administrator. Sometimes determining where one ends and the other begins is more difficult when a single person or small group develops, admin- isters and uses the application. This chapter will look at: • Application developer’s perspective • System administrator’s perspective • Total system resource perspective • Rules of performance tuning 1.1 Application Developer’s Perspective The tasks of the application developer include: • Defining the application • Determining the specifications • Designing application components • Developing the application codes • Testing, tuning, and debugging • Deploying the system and application • Maintaining the system and application 3 4 Chapter 1 • Introduction to Performance Management 1.1.1 Defining the Application The first step is to determine what the application is going to be. Initially, management may need to define the priorities of the development group. Surveys of user organizations may also be carried out. 1.1.2 Determining Application Specifications Defining what the application will accomplish is necessary before any code is written. The users and developers should agree, in advance, on the particular features and/or functionality that the application will provide. Often, performance specifications are agreed upon at this time, and these are typically expressed in terms of user response time or system throughput measures.
    [Show full text]