DOCSLIB.ORG

CSCI [4|6] 730 Operating Systems Scheduling Plans

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CSCI [4|6] 730 Operating Systems Scheduling Plans CSCI [4|6] 730 Operating Systems CPU Scheduling Maria Hybinette, UGA Scheduling Plans • Introductory Concepts • Embellish on the introductory concepts • Case studies • Look at real time scheduling. – Practical system have some theory, and lots of tweaking (hacking). Maria Hybinette, UGA Why Schedule? Management of Resources • Resource: Anything that can be used by only a single [set] process(es) at any instant in time – Not just the CPU, what else? • Hardware device or a piece of information – Examples: • CPU (time, time slice) • Tape drive, Disk space, Memory (spatial) • Locked record in a database (information, synchronization) • Focus today managing the CPU, short term scheduling. Maria Hybinette, UGA Multilevel Feedback Queue • Give new processes high priority and small time slice (preference to smaller jobs) • If process doesn‘t finish job bump it to the next lower level priority queue (with a larger time-slice). • Common in interactive system Maria Hybinette, UGA Case Studies: Early Scheduling Implementations • Windows and Early MS-DOS – Non-Multitasking (so no scheduler needed) • Mac OS 9 – Kernel schedule processes: • A Round Robin Preemptive (fair, each process gets a fair share of CPU – Processes • schedules multiple (MACH) threads that use a cooperative thread schedule manager – each process has its own copy of the scheduler. Maria Hybinette, UGA Case Studies: Modern Scheduling Implementations • Multilevel Feedback Queue w/ Preemption: – FreeBSD, NetBSD Solaris, Linux pre 2.5 – Example Linux: 0-99 real time tasks (200ms quanta), 100-140 nice tasks (10 ms quanta -> expired queue) • Cooperative Scheduling (no preemption) – Windows 3.1x, Mac OS pre3 (thread level) • O(1) Scheduling – time to schedule independent of number of tasks in system – Linux 2.5-2.6.24 ((v2.6.0 first version ~2003/2004) • Completely Fair Scheduler (link read) – Maximizes CPU utilization while maximizing interactive performance / Red/Black Tree instead of Queue – Linux 2.6.23+ Maria Hybinette, UGA Review: Real World Scheduling: • Characteristics of the processes – Are they I/O bound or CPU bound? – Do we have statistics about the processes, e.g., deadlines? – Is their behavior predictable? • Characteristics of the machine – How many CPUs or cores? – Can we preempt processes? – How is memory shared by the CPUs? • Characteristics of the user – Are the processes interactive (e.g. desktop apps)? • Drove the the development of Linux Scheduling protocols. – Or are the processes background jobs? Maria Hybinette, UGA http://pages.cs.wisc.edu/~remzi/OSTEP/ Basic Scheduler Architecture • Scheduler selects from the ready processes, and assigns them to a CPU – System may have >1 CPU – Various different approaches for selecting processes • Scheduling decisions are made when a process: 1. Switches from running to waiting No preemption 2. Terminates 3. Switches from running to ready Preemption 4. Switches from waiting to ready • Scheduler may have access to additional information – Process deadlines, data in shared memory, etc. Maria Hybinette, UGA Beware: Dispatch Latency • The dispatcher gives control of the CPU to the process selected by the scheduler – Switches context – Switching to/from kernel mode/user mode – Saving the old EIP, loading the new EIP • Warning: dispatching incurs a cost – Context switching and mode switch are expensive – Adds latency to processing times • It is advantageous to minimize process switching Maria Hybinette, UGA Review: Scheduling Optimization Criteria • Max CPU utilization – keep the CPU as busy as possible • Max throughput – # of processes that finish over time – Min turnaround• No scheduler time – amount can of meet time to all finish these a process criteria – • Min Which waiting criteria time – amountare most of time important a ready processdepend has on been types waiting of to execute processes and expectations of the system • Min response• E.g. time response – amount time is timekey on between the desktop submitting a request• Throughput and receiving is more a response important for MapReduce – E.g. time between clicking a button and seeing a response • Fairness – all processes receive min/max fair CPU resources 11 Maria Hybinette, UGA Interactive Systems & Tension • Imagine you are typing/clicking in a desktop app – You don’t care about turnaround time – What you care about is responsiveness • E.g. if you start typing but the app doesn’t show the text for 10 seconds, you’ll become frustrated • Response time = first run time – arrival time – Round Robin • Turn around time : – SJCF 12 Maria Hybinette, UGA Proce Burst Arriva ss Time l Time RR vs. STCF P1 6 0 P2 8 0 P3 10 0 P1 P2 P3 STCF Time: 0 6 14 24 • Avg. turnaround time: (6 + 14 + 24) / 3 = 14.7 • Avg. response time: (0 + 6 + 14) / 3 = 6.7 P1 P2 P3 P1 P2 P3 P1 P2 P3 P2 P3 Time: 0 2 4 6 8 10 12 14 16 18 20 24 RR • 2 second time slices • Avg. turnaround time: (14 + 20 + 24) / 3 = 19.3 • Avg. response time: (0 + 2 + 4) / 3 = 2 Maria Hybinette, UGA Tradeoffs RR STCF + Excellent response times + Achieves optimal, low + With N process and time slice of turnaround times Q… - Bad response times + No process waits more than (N-1)/Q time slices - Inherently unfair + Achieves fairness - Short jobs finish first + Each process receives 1/N CPU time - Worst possible turnaround times - If Q is large ! FIFO behavior • Optimizing for turnaround or response time is a trade-off • Achieving both requires more sophisticated algorithms Maria Hybinette, UGA Earliest Deadline First (EDF) • Each process has a deadline it must finish by • Priorities are assigned according to deadlines – Tighter deadlines are given higher priority Process Burst Arrival Dead Time Time line P1 15 0 40 P2 3 4 10 P1 P2 P1 P3 P4 P3 P1 P3 6 10 20 0 4 7 10 13 17 20 28 P4 4 13 18 • EDF is optimal (assuming preemption) [uniprocessors] • But, it’s only useful if processes have known deadlines – Typically used in real-time OS’s Maria Hybinette, UGA https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling Rules of MFLQ • Rule 1: If Priority(A) > Priority(B), A runs, B doesn’t • Rule 2: If Priority(A) = Priority(B), A & B run in RR • Rule 3: Processes start at the highest priority • Rule 4: – Rule 4a: If a process uses an entire time slice while running, its priority is reduced – Rule 4b: If a process gives up the CPU before its time slice is up, it remains at the same priority level 16 Maria Hybinette, UGA Problems With MLFQ So Far… Q0 High priority processes Q1 always take • Starvation precedence Q2sleep(1ms) just before over low time slice expires priority Time: 0 2 4 6 8 10 12 14 Unscrupulous Q0 process never gets Q1 • Cheating demoted, Q2 monopolizes CPU time Time: 0 2 4 6 8 10 12 14 17 Maria Hybinette, UGA MLFQ Rule 5: Priority Boost • Rule 5: After some time period S, move all processes to the highest priority queue • Solves two problems: – Starvation: low priority processes will eventually become high priority, acquire CPU time – Dynamic behavior: a CPU bound process that has become interactive will now be high priority 18 Maria Hybinette, UGA Priority Boost Example Priority Starvation :( Boost Without Priority Boost With Priority Boost Q0 Q0 Q1 Q1 Q2 Q2 Time: 0 2 4 6 8 10 12 14 Time: 0 2 4 6 8 10 12 14 16 18 19 Maria Hybinette, UGA Revised Rule 4: Cheat Prevention • Rule 4a and 4b let a process game the scheduler – Repeatedly yield just before the time limit expires • Solution: better accounting – Rule 4: Once a process uses up its time allotment at a given priority (regardless of whether it gave up the CPU), demote its priority – Basically, keep track of total CPU time used by each process during each time interval S • Instead of just looking at continuous CPU time 20 Maria Hybinette, UGA Preventing Cheating Time Time sleep(1ms) just before allotment allotment time slice expires exhausted exhausted Without Cheat Prevention With Cheat Prevention Q0 Q0 Q1 Q1 Q2 Q2 Time: 0 2 4 6 8 10 12 14 Time: 0 2 4 6 8 10 12 14 16 Round robin 21 Maria Hybinette, UGA MLFQ Rule Review • Rule 1: If Priority(A) > Priority(B), A runs, B doesn’t • Rule 2: If Priority(A) = Priority(B), A & B run in RR • Rule 3: Processes start at the highest priority • Rule 4: Once a process uses up its time allotment at a given priority, demote it • Rule 5: After some time period S, move all processes to the highest priority queue 22 Maria Hybinette, UGA Parameterizing MLFQ • MLFQ meets our goals – Balances response time and turnaround time – Does not require prior knowledge about processes • But, it has many knobs to tune – Number of queues? – How to divide CPU time between the queues? – For each queue: • Which scheduling regime to use? • Time slice/quantum? – Method for demoting priorities? – Method for boosting priorities? 23 Maria Hybinette, UGA MLFQ In Practice • Many OSs use MLFQ-like schedulers – Example: Windows NT/2000/XP/Vista, Solaris, FreeBSD • OSs ship with “reasonable” MLFQ parameters – Variable length time slices • High priority queues – short time slices • Low priority queues – long time slices – Priority 0 sometimes reserved for OS processes 24 Maria Hybinette, UGA Giving Hints/Advice • Some OSes allow users/processes to give the scheduler “hints” about priorities • Example: nice command on Linux $ nice <options> <command [args …]> – Run the command at the specified priority – Priorities range from -20 (high) to 19 (low) 25 Maria Hybinette, UGA Recap • So-far schedulers discussed are designed to optimize performance: – Minimum response times – Minimum turnaround times • MLFQ achieves these goals, but it’s complicated
Load more

Recommended publications
  • Kernel-Scheduled Entities for Freebsd
    Kernel-Scheduled Entities for FreeBSD Jason Evans [email protected] November 7, 2000 Abstract FreeBSD has historically had less than ideal support for multi-threaded application programming. At present, there are two threading libraries available. libc r is entirely invisible to the kernel, and multiplexes threads within a single process. The linuxthreads port, which creates a separate process for each thread via rfork(), plus one thread to handle thread synchronization, relies on the kernel scheduler to multiplex ”threads” onto the available processors. Both approaches have scaling problems. libc r does not take advantage of multiple processors and cannot avoid blocking when doing I/O on ”fast” devices. The linuxthreads port requires one process per thread, and thus puts strain on the kernel scheduler, as well as requiring significant kernel resources. In addition, thread switching can only be as fast as the kernel's process switching. This paper summarizes various methods of implementing threads for application programming, then goes on to describe a new threading architecture for FreeBSD, based on what are called kernel- scheduled entities, or scheduler activations. 1 Background FreeBSD has been slow to implement application threading facilities, perhaps because threading is difficult to implement correctly, and the FreeBSD's general reluctance to build substandard solutions to problems. Instead, two technologies originally developed by others have been integrated. libc r is based on Chris Provenzano's userland pthreads implementation, and was significantly re- worked by John Birrell and integrated into the FreeBSD source tree. Since then, numerous other people have improved and expanded libc r's capabilities. At this time, libc r is a high-quality userland implementation of POSIX threads.
    [Show full text]
  • Lecture 11: Deadlock, Scheduling, & Synchronization October 3, 2019 Instructor: David E
    CS 162: Operating Systems and System Programming Lecture 11: Deadlock, Scheduling, & Synchronization October 3, 2019 Instructor: David E. Culler & Sam Kumar https://cs162.eecs.berkeley.edu Read: A&D 6.5 Project 1 Code due TOMORROW! Midterm Exam next week Thursday Outline for Today • (Quickly) Recap and Finish Scheduling • Deadlock • Language Support for Concurrency 10/3/19 CS162 UCB Fa 19 Lec 11.2 Recall: CPU & I/O Bursts • Programs alternate between bursts of CPU, I/O activity • Scheduler: Which thread (CPU burst) to run next? • Interactive programs vs Compute Bound vs Streaming 10/3/19 CS162 UCB Fa 19 Lec 11.3 Recall: Evaluating Schedulers • Response Time (ideally low) – What user sees: from keypress to character on screen – Or completion time for non-interactive • Throughput (ideally high) – Total operations (jobs) per second – Overhead (e.g. context switching), artificial blocks • Fairness – Fraction of resources provided to each – May conflict with best avg. throughput, resp. time 10/3/19 CS162 UCB Fa 19 Lec 11.4 Recall: What if we knew the future? • Key Idea: remove convoy effect –Short jobs always stay ahead of long ones • Non-preemptive: Shortest Job First – Like FCFS where we always chose the best possible ordering • Preemptive Version: Shortest Remaining Time First – A newly ready process (e.g., just finished an I/O operation) with shorter time replaces the current one 10/3/19 CS162 UCB Fa 19 Lec 11.5 Recall: Multi-Level Feedback Scheduling Long-Running Compute Tasks Demoted to Low Priority • Intuition: Priority Level proportional
    [Show full text]
  • Process Scheduling Ii
    PROCESS SCHEDULING II CS124 – Operating Systems Spring 2021, Lecture 12 2 Real-Time Systems • Increasingly common to have systems with real-time scheduling requirements • Real-time systems are driven by specific events • Often a periodic hardware timer interrupt • Can also be other events, e.g. detecting a wheel slipping, or an optical sensor triggering, or a proximity sensor reaching a threshold • Event latency is the amount of time between an event occurring, and when it is actually serviced • Usually, real-time systems must keep event latency below a minimum required threshold • e.g. antilock braking system has 3-5 ms to respond to wheel-slide • The real-time system must try to meet its deadlines, regardless of system load • Of course, may not always be possible… 3 Real-Time Systems (2) • Hard real-time systems require tasks to be serviced before their deadlines, otherwise the system has failed • e.g. robotic assembly lines, antilock braking systems • Soft real-time systems do not guarantee tasks will be serviced before their deadlines • Typically only guarantee that real-time tasks will be higher priority than other non-real-time tasks • e.g. media players • Within the operating system, two latencies affect the event latency of the system’s response: • Interrupt latency is the time between an interrupt occurring, and the interrupt service routine beginning to execute • Dispatch latency is the time the scheduler dispatcher takes to switch from one process to another 4 Interrupt Latency • Interrupt latency in context: Interrupt! Task
    [Show full text]
  • Embedded Systems
    Sri Chandrasekharendra Saraswathi Viswa Maha Vidyalaya Department of Electronics and Communication Engineering STUDY MATERIAL for III rd Year VI th Semester Subject Name: EMBEDDED SYSTEMS Prepared by Dr.P.Venkatesan, Associate Professor, ECE, SCSVMV University Sri Chandrasekharendra Saraswathi Viswa Maha Vidyalaya Department of Electronics and Communication Engineering PRE-REQUISITE: Basic knowledge of Microprocessors, Microcontrollers & Digital System Design OBJECTIVES: The student should be made to – Learn the architecture and programming of ARM processor. Be familiar with the embedded computing platform design and analysis. Be exposed to the basic concepts and overview of real time Operating system. Learn the system design techniques and networks for embedded systems to industrial applications. Sri Chandrasekharendra Saraswathi Viswa Maha Vidyalaya Department of Electronics and Communication Engineering SYLLABUS UNIT – I INTRODUCTION TO EMBEDDED COMPUTING AND ARM PROCESSORS Complex systems and micro processors– Embedded system design process –Design example: Model train controller- Instruction sets preliminaries - ARM Processor – CPU: programming input and output- supervisor mode, exceptions and traps – Co- processors- Memory system mechanisms – CPU performance- CPU power consumption. UNIT – II EMBEDDED COMPUTING PLATFORM DESIGN The CPU Bus-Memory devices and systems–Designing with computing platforms – consumer electronics architecture – platform-level performance analysis - Components for embedded programs- Models of programs-
    [Show full text]
  • Advanced Scheduling
    Administrivia • Project 1 due Friday noon • If you need longer, email cs140-staff. - Put “extension” in the subject - Tell us where you are, and how much longer you need. - We will give short extensions to people who don’t abuse this • Section Friday to go over project 2 • Project 2 Due Friday, Feb. 7 at noon • Midterm following Monday, Feb. 10 • Midterm will be open book, open notes - Feel free to bring textbook, printouts of slides - Laptop computers or other electronic devices prohibited 1 / 38 Fair Queuing (FQ) [Demers] • Digression: packet scheduling problem - Which network packet should router send next over a link? - Problem inspired some algorithms we will see today - Plus good to reinforce concepts in a different domain. • For ideal fairness, would use bit-by-bit round-robin (BR) - Or send more bits from more important flows (flow importance can be expressed by assigning numeric weights) Flow 1 Flow 2 Round-robin service Flow 3 Flow 4 2 / 38 SJF • Recall limitations of SJF from last lecture: - Can’t see the future . solved by packet length - Optimizes response time, not turnaround time . but these are the same when sending whole packets - Not fair Packet scheduling • Differences from CPU scheduling - No preemption or yielding—must send whole packets . Thus, can’t send one bit at a time - But know how many bits are in each packet . Can see the future and know how long packet needs link • What scheduling algorithm does this suggest? 3 / 38 Packet scheduling • Differences from CPU scheduling - No preemption or yielding—must send whole packets .
    [Show full text]
  • Lottery Scheduling in the Linux Kernel: a Closer Look
    LOTTERY SCHEDULING IN THE LINUX KERNEL: A CLOSER LOOK A Thesis presented to the Faculty of California Polytechnic State University, San Luis Obispo In Partial Fulfillment of the Requirements for the Degree Master of Science in Computer Science by David Zepp June 2012 © 2012 David Zepp ALL RIGHTS RESERVED ii COMMITTEE MEMBERSHIP TITLE: LOTTERY SCHEDULING IN THE LINUX KERNEL: A CLOSER LOOK AUTHOR: David Zepp DATE SUBMITTED: June 2012 COMMITTEE CHAIR: Michael Haungs, Associate Professor of Computer Science COMMITTEE MEMBER: John Bellardo, Assistant Professor of Computer Science COMMITTEE MEMBER: Aaron Keen, Associate Professor of Computer Science iii ABSTRACT LOTTERY SCHEDULING IN THE LINUX KERNEL: A CLOSER LOOK David Zepp This paper presents an implementation of a lottery scheduler, presented from design through debugging to performance testing. Desirable characteristics of a general purpose scheduler include low overhead, good overall system performance for a variety of process types, and fair scheduling behavior. Testing is performed, along with an analysis of the results measuring the lottery scheduler against these characteristics. Lottery scheduling is found to provide better than average control over the relative execution rates of processes. The results show that lottery scheduling functions as a good mechanism for sharing the CPU fairly between users that are competing for the resource. While the lottery scheduler proves to have several interesting properties, overall system performance suffers and does not compare favorably with the balanced performance afforded by the standard Linux kernel’s scheduler. Keywords: lottery scheduling, schedulers, Linux iv TABLE OF CONTENTS LIST OF TABLES…………………………………………………………………. vi LIST OF FIGURES……………………………………………………………….... vii CHAPTER 1. Introduction................................................................................................... 1 2.
    [Show full text]
  • Multilevel Feedback Queue Scheduling Program in C
    Multilevel Feedback Queue Scheduling Program In C Matias is featureless and carnalize lethargically while psychical Nestor ruralized and enamelling. Wallas live asleep while irreproducible Hallam immolate paramountly or ogle wholly. Pertussal Hale cutinize schismatically and circularly, she caponizes her exanimation licences ineluctably. Under these lengths, higher priority queue program just for scheduling program in multilevel feedback queue allows movement of this multilevel queue Operating conditions of scheduling program in multilevel feedback queue have issue. Operating System OS is but software which acts as an interface between. Jumping to propose proper location in the user program to restart. N Multilevel-feedback-queue scheduler defined by treaty following parameters number. A fixed time is allotted to every essence that arrives in better queue. Why review it where for the scheduler to distinguish IO-bound programs from. Computer Scheduler Multilevel Feedback to question. C Program For Multilevel Feedback Queue Scheduling Algorithm. Of the program but spend the parameters like a UNIX command line. Roadmap Multilevel Queue Scheduling Multilevel Queue Example. CPU Scheduling Algorithms in Operating Systems Guru99. How would a queue program as well organized as improving the survey covered include distributed computing. Multilevel Feedback Queue Scheduling MLFQ CPU Scheduling. A skip of Scheduling parallel program tasks DOI. Please chat if a computer systems and shortest tasks, the waiting time quantum increases context is quite complex, multilevel feedback queue scheduling algorithms like the higher than randomly over? Scheduling of Processes. Suppose now the dispatcher uses an algorithm that favors programs that have used. Data on a scheduling c time for example of the process? You need a feedback scheduling is longer than the line records? PowerPoint Presentation.
    [Show full text]
  • (FCFS) Scheduling
    Lecture 4: Uniprocessor Scheduling Prof. Seyed Majid Zahedi https://ece.uwaterloo.ca/~smzahedi Outline • History • Definitions • Response time, throughput, scheduling policy, … • Uniprocessor scheduling policies • FCFS, SJF/SRTF, RR, … A Bit of History on Scheduling • By year 2000, scheduling was considered a solved problem “And you have to realize that there are not very many things that have aged as well as the scheduler. Which is just another proof that scheduling is easy.” Linus Torvalds, 2001[1] • End to Dennard scaling in 2004, led to multiprocessor era • Designing new (multiprocessor) schedulers gained traction • Energy efficiency became top concern • In 2016, it was shown that bugs in Linux kernel scheduler could cause up to 138x slowdown in some workloads with proportional energy waist [2] [1] L. Torvalds. The Linux Kernel Mailing List. http://tech-insider.org/linux/research/2001/1215.html, Feb. 2001. [2] Lozi, Jean-Pierre, et al. "The Linux scheduler: a decade of wasted cores." Proceedings of the Eleventh European Conference on Computer Systems. 2016. Definitions • Task, thread, process, job: unit of work • E.g., mouse click, web request, shell command, etc.) • Workload: set of tasks • Scheduling algorithm: takes workload as input, decides which tasks to do first • Overhead: amount of extra work that is done by scheduler • Preemptive scheduler: CPU can be taken away from a running task • Work-conserving scheduler: CPUs won’t be left idle if there are ready tasks to run • For non-preemptive schedulers, work-conserving is not always
    [Show full text]
  • Lottery Scheduler for the Linux Kernel Planificador Lotería Para El Núcleo
    Lottery scheduler for the Linux kernel María Mejía a, Adriana Morales-Betancourt b & Tapasya Patki c a Universidad de Caldas and Universidad Nacional de Colombia, Manizales, Colombia, [email protected] b Departamento de Sistemas e Informática at Universidad de Caldas, Manizales, Colombia, [email protected] c Department of Computer Science, University of Arizona, Tucson, USA, [email protected] Received: April 17th, 2014. Received in revised form: September 30th, 2014. Accepted: October 20th, 2014 Abstract This paper describes the design and implementation of Lottery Scheduling, a proportional-share resource management algorithm, on the Linux kernel. A new lottery scheduling class was added to the kernel and was placed between the real-time and the fair scheduling class in the hierarchy of scheduler modules. This work evaluates the scheduler proposed on compute-intensive, I/O-intensive and mixed workloads. The results indicate that the process scheduler is probabilistically fair and prevents starvation. Another conclusion is that the overhead of the implementation is roughly linear in the number of runnable processes. Keywords: Lottery scheduling, Schedulers, Linux kernel, operating system. Planificador lotería para el núcleo de Linux Resumen Este artículo describe el diseño e implementación del planificador Lotería en el núcleo de Linux, este planificador es un algoritmo de administración de proporción igual de recursos, Una nueva clase, el planificador Lotería (Lottery scheduler), fue adicionado al núcleo y ubicado entre la clase de tiempo-real y la clase de planificador completamente equitativo (Complete Fair scheduler-CFS) en la jerarquía de los módulos planificadores. Este trabajo evalúa el planificador propuesto en computación intensiva, entrada-salida intensiva y cargas de trabajo mixtas.
    [Show full text]
  • 2. Virtualizing CPU(2)
    Operating Systems 2. Virtualizing CPU Pablo Prieto Torralbo DEPARTMENT OF COMPUTER ENGINEERING AND ELECTRONICS This material is published under: Creative Commons BY-NC-SA 4.0 2.1 Virtualizing the CPU -Process What is a process? } A running program. ◦ Program: Static code and static data sitting on the disk. ◦ Process: Dynamic instance of a program. ◦ You can have multiple instances (processes) of the same program (or none). ◦ Users usually run more than one program at a time. Web browser, mail program, music player, a game… } The process is the OS’s abstraction for execution ◦ often called a job, task... ◦ Is the unit of scheduling Program } A program consists of: ◦ Code: machine instructions. ◦ Data: variables stored and manipulated in memory. Initialized variables (global) Dynamically allocated (malloc, new) Stack variables (function arguments, C automatic variables) } What is added to a program to become a process? ◦ DLLs: Libraries not compiled or linked with the program (probably shared with other programs). ◦ OS resources: open files… Program } Preparing a program: Task Editor Source Code Source Code A B Compiler/Assembler Object Code Object Code Other A B Objects Linker Executable Dynamic Program File Libraries Loader Executable Process in Memory Process Creation Process Address space Code Static Data OS res/DLLs Heap CPU Memory Stack Loading: Code OS Reads on disk program Static Data and places it into the address space of the process Program Disk Eagerly/Lazily Process State } Each process has an execution state, which indicates what it is currently doing ps -l, top ◦ Running (R): executing on the CPU Is the process that currently controls the CPU How many processes can be running simultaneously? ◦ Ready/Runnable (R): Ready to run and waiting to be assigned by the OS Could run, but another process has the CPU Same state (TASK_RUNNING) in Linux.
    [Show full text]
  • Processor Affinity Or Bound Multiprocessing?
    Processor Affinity or Bound Multiprocessing? Easing the Migration to Embedded Multicore Processing Shiv Nagarajan, Ph.D. QNX Software Systems [email protected] Processor Affinity or Bound Multiprocessing? QNX Software Systems Abstract Thanks to higher computing power and system density at lower clock speeds, multicore processing has gained widespread acceptance in embedded systems. Designing systems that make full use of multicore processors remains a challenge, however, as does migrating systems designed for single-core processors. Bound multiprocessing (BMP) can help with these designs and these migrations. It adds a subtle but critical improvement to symmetric multiprocessing (SMP) processor affinity: it implements runmask inheritance, a feature that allows developers to bind all threads in a process or even a subsystem to a specific processor without code changes. QNX Neutrino RTOS Introduction The QNX® Neutrino® RTOS has been Effective use of multicore processors can multiprocessor capable since 1997, and profoundly improve the performance of embedded is deployed in hundreds of systems and applications ranging from industrial control systems thousands of multicore processors in to multimedia platforms. Designing systems that embedded environments. It supports make effective use of multiprocessors remains a AMP, SMP — and BMP. challenge, however. The problem is not just one of making full use of the new multicore environments to optimize performance. Developers must not only guarantee that the systems they themselves write will run correctly on multicore processors, but they must also ensure that applications written for single-core processors will not fail or cause other applications to fail when they are migrated to a multicore environment. To complicate matters further, these new and legacy applications can contain third-party code, which developers may not be able to change.
    [Show full text]
  • CPU Scheduling
    CPU Scheduling CS 416: Operating Systems Design Department of Computer Science Rutgers University http://www.cs.rutgers.edu/~vinodg/teaching/416 What and Why? What is processor scheduling? Why? At first to share an expensive resource ± multiprogramming Now to perform concurrent tasks because processor is so powerful Future looks like past + now Computing utility – large data/processing centers use multiprogramming to maximize resource utilization Systems still powerful enough for each user to run multiple concurrent tasks Rutgers University 2 CS 416: Operating Systems Assumptions Pool of jobs contending for the CPU Jobs are independent and compete for resources (this assumption is not true for all systems/scenarios) Scheduler mediates between jobs to optimize some performance criterion In this lecture, we will talk about processes and threads interchangeably. We will assume a single-threaded CPU. Rutgers University 3 CS 416: Operating Systems Multiprogramming Example Process A 1 sec start idle; input idle; input stop Process B start idle; input idle; input stop Time = 10 seconds Rutgers University 4 CS 416: Operating Systems Multiprogramming Example (cont) Process A Process B start B start idle; input idle; input stop A idle; input idle; input stop B Total Time = 20 seconds Throughput = 2 jobs in 20 seconds = 0.1 jobs/second Avg. Waiting Time = (0+10)/2 = 5 seconds Rutgers University 5 CS 416: Operating Systems Multiprogramming Example (cont) Process A start idle; input idle; input stop A context switch context switch to B to A Process B idle; input idle; input stop B Throughput = 2 jobs in 11 seconds = 0.18 jobs/second Avg.
    [Show full text]