DOCSLIB.ORG

CS 4310: Operating Systems Lecture Notes - Student Version∗

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CS 4310: Operating Systems Lecture Notes - Student Version∗ CS 4310: Operating Systems Lecture Notes - Student Version∗ Kyle Burke January 10, 2018 Contents -1.0 Using Chapel . 2 0 OS Basics 2 0.1 Interrupts . 2 1 Parallel Programming (using Chapel) 2 2 Hardware Threads 2 3 Concurrency 3 4 Semaphores 4 5 The Producer-Consumer Problem 4 5.1 Circular Queues . 4 6 Memory Management 6 7 Stack vs. Heap 8 7.1 Stack Management . 9 7.2 Heap Management . 9 8 Scheduling 9 8.1 Shortest-Job First . 10 8.2 First Come, First Serve . 13 8.3 Earliest-Deadline First . 14 8.4 Round Robin . 15 8.5 Hybrid Schedulers . 15 8.6 Examples . 15 9 Interrupts 20 10 File Systems 24 10.1 Fragmentation . 27 11 OS Security 31 12 History of OSes by Candace 31 ∗Created with lectureNotes.sty, which is available at: http://turing.plymouth.edu/~kgb1013/lectureNotesLatexStyle.php (or, GitHub: https://github.com/paithan/LaTeX-LectureNotes). Many or most of the answers to questions are hidden so that some of class will still be a challenge for students. 1 -1.0 Using Chapel 2 HARDWARE THREADS -1.0 Using Chapel This course was last taught with programming assignments given in Chapel1 using compiler version 1.14. This is a High-Performance Computing language designed to make parallel programming easier for computational scientists. Here are some comments about this language. • It makes launching threads and handling synchronization very easy. • It is missing many of the basic libraries that exist for common languages (e.g. Java). • Goal: focus on the 0 OS Basics 〈 Go over syllabus! 〉 Q: What are the responsibilities of an Operating System? What do they do? A: • TODO 0.1 Interrupts This material is currently in 9. Should we move it? 1 Parallel Programming (using Chapel) 2 Hardware Threads Q: How many hardware threads do your computers have? How many CPUs? (Might be different numbers.) Q: How can a CPU have multiple threads? A: TODO: add stuff here? Picture, maybe? 1http://chapel.cray.com © 2018 Kyle Burke 3 CONCURRENCY Q: What if you have more threads than that? A: Q: What are some of the parts of a PCB? ID Unique identification number for this process. State "New", "Ready", "Running", "Blocking", etc. Program Counter : Pointer to the address of the next line of code to execute. Registers Data that will be loaded into the registers when this executes. Process Scheduling State "Ready" or "Suspended". A: Could include info about the priority. Process Structuring Information IDs of any chil- dren processes. Interprocess communication info Links to any other processes or variables outside of this process that are relevant. Privileges What are the privileges of this process? (User/superuser, etc) And more! Q: Do PCBs go on the stack or the heap? A: 3 Concurrency 〈 Do a Dining Philosophers live-action example. Show a deadlock. (Tell everyone to pick up their right-hand fork first, then tell them all that they’re hungry.) 〉 〈 Talk about the following things: © 2018 Kyle Burke 5 THE PRODUCER-CONSUMER PROBLEM • Concurrent Threads/Processes • Race conditions • Critical Section code - code where race conditions can occur. • Mutual Exclusion (mutex) - property of concurrent programming where only one thread can execute its critical section at a time. • Lock: Actual mechanism to enforce mutual exclusion. We will use semaphores. 〉 Q: What are the four steps for a thread executing a critical section? 1. Non-critical: Code is not executing a critical section. 2. Try: Before entering a critical section, the thread requests access. A: 3. Critical section: The thread executes the critical section. No other threads are simultaneously exe- cuting their critical sections. 4. Exit: The thread exits the critical section, freeing up the lock. 4 Semaphores 〈 How can we use semaphores as locks? 〉 〈 Do dining philosophers again. 〉 Q: How many semaphores are we using? 5 The Producer-Consumer Problem 〈 Quickly describe the Producer-Consumer problem. 〉 Common solution: give them a buffer of items produced, but not yet consumed. 5.1 Circular Queues 〈 Explain need for a bounded-size buffer. 〉 〈 Buffer should be a queue. 〉 © 2018 Kyle Burke 5.1 Circular Queues 5 THE PRODUCER-CONSUMER PROBLEM 〈 Two common options: Linked List or Circular array. Quickly describe each. 〉 Q: What’s the pro for each? A: Q: How can we speed the circular array up? A: Q: When should I not be able to add to the circular array? A: When it is full. Q: What should happen to the thread that’s trying to add to it? A: Block! Q: Until when? A: Q: When should I not be able to remove from the circular array? A: © 2018 Kyle Burke 6 MEMORY MANAGEMENT Q: What should happen to a thread trying to remove something? A: Q: How can we enforce these blocking behaviors? A: Q: How many semaphores does each blocking queue need? A: 〈 Talk about whether 2 is enough! 〉 6 Memory Management OS Takes up some memory space. ("Linux Kernel") Remainder goes to the applications that will run on top of the OS. Q: How big are modern OS kernels? A: Memory Management Techniques • Single contiguous Allocation: all the memory is available to one application. (MSDOS, Single-purpose hardware.) © 2018 Kyle Burke 6 MEMORY MANAGEMENT • Partitioned Allocation: Memory is divided up into separate partitions (maybe by appli- cation or process). Need to allocate space when jobs/applications start and deallocate when they stop. • Paged Allocation: Memory is divided up into fixed size page frames. These pages do not need to be contiguous in RAM. Addresses: (page, offset). Hardware Memory Management Unit (MMU) is needed to convert page indices to actual RAM addresses. • Memory Segmentation: divided into variable-size segments. Addresses: (segment, off- set). MMU translates these pairs into physical addresses. (Implements Segment Table.) Segmentation Fault: Tried to access an offset too big for the given segment. Q: Pros and Cons. Which has most overhead? Which is most flexible? Which is most used? Q: What is Virtual Memory? A: 2 2VM Image source: https://commons.wikimedia.org/wiki/File:Virtual_memory.svg © 2018 Kyle Burke 7 STACK VS. HEAP Q: What is the distinction between page, page frame, and paging? • A page is a fixed-length piece of VM. A: • A page frame is a fixed-length piece of RAM. • Paging is process of exchanging pages from hard drive to RAM as needed. AKA swapping. Q: Can we have VM without paging? A: Q: Pros and Cons? Q: Can we use Segmentation technique with paging? A: Nice bonus of VM: each application/process could get it’s own contiguous space, a la Partitioned Allocation. Thus, each could have it’s own Stack and Heap. Note: may have to share some heap parts with other processes. 7 Stack vs. Heap "The Stack", also known as call stack, stores data about currently-running code. What does top stack frame look like? • Process Control Block up top (small) • Lines of code from module below • Data below that. • Other stack frames below that. © 2018 Kyle Burke 7.1 Stack Management 8 SCHEDULING 7.1 Stack Management 7.2 Heap Management 〈 Just go over the notes from CS 232. I should probably copy them over here, but I haven’t done that yet... 〉 8 Scheduling 〈 Talk about traffic lights, train tunnels, etc. 〉 Q: What are different goals for scheduling? A: Q: Okay, so what properties of a "Job" might a scheduler want to know? A: © 2018 Kyle Burke 8.1 Shortest-Job First 8 SCHEDULING Q: What are some possible ways you would choose which process gets to run next? What do you think are common scheduling algorithms? A: Q: What is preemptive? A: 8.1 Shortest-Job First SJF minimizes total waiting time and latency. Q: What’s the benefit of shortest job first? A: © 2018 Kyle Burke 8.1 Shortest-Job First 8 SCHEDULING Let’s say I have four processes: A, B, C, D. Each has the following running times: • A: 5 ms Q: • B: 10 ms • C: 7 ms • D: 3 ms How long does it take to run all the processes using SJF? (Assume negligible context switching.) A: Q: Is that any faster if I rearrange them? A: Q: So how does the order change the latency? I’ve still got to wait 25 ms to complete them all! A: Q: What’s the latency for each of the four processes using SJF? A: © 2018 Kyle Burke 8.1 Shortest-Job First 8 SCHEDULING Q: So average? A: Q: What if we aren’t using SJF and instead do them in the order D, A, B, C? What is the average latency now? A: Q: How long to add something to the scheduler? A: Q: How long to remove the next process to run? A: Q: What’s a big issue with SJF? What’s a problem with this algorithm? A: Starvation: One (or more) processes never get executed. © 2018 Kyle Burke 8.2 First Come, First Serve 8 SCHEDULING Q: How could this happen? A: Q: Could there be a preemptive version of SJF? Q: How does that work? 8.2 First Come, First Serve Q: Which property does FCFS optimize for? A: Q: How long to add something to the scheduler? A: Q: How long to remove the next process to run? A: Q: Could there be a preemptive version of this? A: © 2018 Kyle Burke 8.3 Earliest-Deadline First 8 SCHEDULING 8.3 Earliest-Deadline First Q: Which property does EDF optimize for? A: Q: What should you do if you can’t make a deadline? A: Q: How long to add something to the scheduler? A: Q: How long to remove the next process to run? A: Q: Could there be a preemptive version of this? A: © 2018 Kyle Burke 8.4 Round Robin 8 SCHEDULING 8.4 Round Robin Q: Which property does Round Robin optimize for? A: Q: How long to add something to the scheduler? A: Q: How long to remove the next process to run? A: Q: Could there be a preemptive version of this? A: 8.5 Hybrid Schedulers 〈 Talk about them.
Load more

Recommended publications
  • A Lecture Note on Csc 322 Operating System I by Dr
    A LECTURE NOTE ON CSC 322 OPERATING SYSTEM I BY DR. S. A. SODIYA 1 SECTION ONE 1.0 INTRODUCTION TO OPERATING SYSTEMS 1.1 DEFINITIONS OF OPERATING SYSTEMS An operating system (commonly abbreviated OS and O/S) is the infrastructure software component of a computer system; it is responsible for the management and coordination of activities and the sharing of the limited resources of the computer. An operating system is the set of programs that controls a computer. The operating system acts as a host for applications that are run on the machine. As a host, one of the purposes of an operating system is to handle the details of the operation of the hardware. This relieves application programs from having to manage these details and makes it easier to write applications. Operating Systems can be viewed from two points of views: Resource manager and Extended machines. From Resource manager point of view, Operating Systems manage the different parts of the system efficiently and from extended machines point of view, Operating Systems provide a virtual machine to users that is more convenient to use. 1.2 HISTORICAL DEVELOPMENT OF OPERATING SYSTEMS Historically operating systems have been tightly related to the computer architecture, it is good idea to study the history of operating systems from the architecture of the computers on which they run. Operating systems have evolved through a number of distinct phases or generations which corresponds roughly to the decades. The 1940's - First Generation The earliest electronic digital computers had no operating systems. Machines of the time were so primitive that programs were often entered one bit at a time on rows of mechanical switches (plug boards).
    [Show full text]
  • Optimizing Storage Performance with Calibrated Interrupts
    Optimizing Storage Performance with Calibrated Interrupts Amy Tai, VMware Research; Igor Smolyar, Technion — Israel Institute of Technology; Michael Wei, VMware Research; Dan Tsafrir, Technion — Israel Institute of Technology and VMware Research https://www.usenix.org/conference/osdi21/presentation/tai This paper is included in the Proceedings of the 15th USENIX Symposium on Operating Systems Design and Implementation. July 14–16, 2021 978-1-939133-22-9 Open access to the Proceedings of the 15th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX. Optimizing Storage Performance with Calibrated Interrupts Amy Tai‡∗ Igor Smolyar†∗ Michael Wei‡ Dan Tsafrir†‡ †Technion – Israel Institute of Technology ‡VMware Research Abstract ever, creates a trade-off between request latency and the inter- After request completion, an I/O device must decide either rupt rate. For the workloads we inspected, CPU utilization in- to minimize latency by immediately firing an interrupt or to creases by as much as 55% without coalescing (Figure 12(d)), optimize for throughput by delaying the interrupt, anticipating while under even the minimum amount of coalescing, request that more requests will complete soon and help amortize the latency increases by as much as 10× for small requests, due interrupt cost. Devices employ adaptive interrupt coalescing to large timeouts. Interrupt coalescing is disabled by default heuristics that try to balance between these opposing goals. in Linux, and real deployments use alternatives (§2). Unfortunately, because devices lack the semantic information This paper addresses the challenge of dealing with expo- about which I/O requests are latency-sensitive, these heuris- nentially increasing interrupt rates without sacrificing latency.
    [Show full text]
  • Fitting Linux Device Drivers Into an Analyzable Scheduling Framework
    Fitting Linux Device Drivers into an Analyzable Scheduling Framework [Extended Abstract] ∗ Theodore P. Baker, An-I Andy Wang, Mark J. Stanovich Florida State University Tallahassee, Florida 32306-4530 [email protected], [email protected], [email protected] ABSTRACT models of the theory. More specifically, applying the theory re- quires that the system workload corresponds to models that have API extensions and performance improvements to the Linux oper- been studied, and that the system schedules the workload accord- ating system now enable it to serve as a platform for a range of ing to one of the algorithms whose performance on such workloads embedded real-time applications, using fixed-priority preemptive has been analyzed. Where a real-time system is implemented on scheduling. Powerful techniques exist for analytical verification of top of an operating system, these requirements apply to all the OS application timing constraints under this scheduling model. How- components as well as the user-level code. ever, when the application is layered over an operating system the operating system must be included in the analysis. In particular, In Linux and several other POSIX/Unix-compliant [31] operating the computational workloads due to device drivers and other in- systems, progress has been made in providing real-time constructs ternal components of the operating system, and the ways they are so that user-level programmers can write applications that adhere scheduled, need to match abstract workload models and schedul- to the theory of fixed-priority preemptive scheduling. Examples in- ing polices that are amenable to analysis. This paper assesses the clude preemptive priority-based real-time scheduling of user threads, degree to which the effects of device drivers in Linux can now be high-precision software timers, and turning off virtual memory man- modeled adequately to admit fixed-priority preemptive schedula- agement for certain memory regions.
    [Show full text]
  • Junos® OS Release 19.3R3 for the ACX Series, EX Series, MX Series, NFX Series, PTX Series, QFX Series, SRX Series, and Junos Fusion
    1 Release Notes: Junos® OS Release 19.3R3 for the ACX Series, EX Series, MX Series, NFX Series, PTX Series, QFX Series, SRX Series, and Junos Fusion 15 July 2021 Contents Introduction | 10 Junos OS Release Notes for ACX Series | 10 What's New | 11 What's New in Release 19.3R3 | 11 What's New in Release 19.3R2 | 11 What’s New in Release 19.3R1-S1 | 11 What's New in Release 19.3R1 | 12 What's Changed | 19 What’s Changed in Release 19.3R3-S1 | 20 What's Changed in Release 19.3R3 | 20 What's Changed in Release 19.3R2-S6 | 20 What's Changed in Release 19.3R2 | 21 What's Changed in Release 19.3R1 | 21 Known Limitations | 23 General Routing | 23 Open Issues | 25 General Routing | 25 Platform and Infrastructure | 27 Virtual Chassis | 27 2 Resolved Issues | 27 Resolved Issues: 19.3R3 | 28 Resolved Issues: 19.3R2 | 30 Resolved Issues: 19.3R1 | 31 Documentation Updates | 34 Migration, Upgrade, and Downgrade Instructions | 35 Upgrade and Downgrade Support Policy for Junos OS Releases | 35 Junos OS Release Notes for EX Series Switches | 37 What's New | 37 What's New in 19.3R3 | 38 What's New in 19.3R2 | 38 What's New in 19.3R1 | 39 What's Changed | 47 What's Changed in 19.3R3 | 48 What's Changed in Release 19.3R2-S6 | 49 What's Changed in 19.3R2 | 50 What's Changed in 19.3R1 | 50 Known Limitations | 51 EVPN | 52 Infrastructure | 52 Platform and Infrastructure | 52 Open Issues | 53 Authentication and Access Control | 53 Infrastructure | 53 Interfaces and Chassis | 54 Layer 2 Features | 54 Network Management and Monitoring | 54 Platform and Infrastructure
    [Show full text]
  • Tolerating Malicious Device Drivers in Linux
    Tolerating Malicious Device Drivers in Linux Silas Boyd-Wickizer and Nickolai Zeldovich MIT CSAIL ABSTRACT driver isolation techniques trust the driver not to subvert the isolation, or not to livelock the system. If attackers This paper presents SUD, a system for running existing Linux device drivers as untrusted user-space processes. exploit a bug in the device driver [1, 5], they can proceed Even if the device driver is controlled by a malicious to subvert the isolation mechanism and compromise the adversary, it cannot compromise the rest of the system. entire system. While some systems can provide stronger One significant challenge of fully isolating a driver is to guarantees [28, 33], they rely on the availability of a fully- trusted, precise specification of the hardware device’s confine the actions of its hardware device. SUD relies on IOMMU hardware, PCI express bridges, and message- behavior, which is rarely available for devices today. signaled interrupts to confine hardware devices. SUD This paper presents the design and implementation of runs unmodified Linux device drivers, by emulating a SUD, a kernel framework that provides complete isolation Linux kernel environment in user-space. A prototype of for untrusted device drivers in Linux, without the need SUD runs drivers for Gigabit Ethernet, 802.11 wireless, for any special programming languages or specifications. sound cards, USB host controllers, and USB devices, and SUD leverages recent hardware support to implement it is easy to add a new device class. SUD achieves the general-purpose mechanisms that ensure a misbehaving same performance as an in-kernel driver on networking driver, and the hardware device that it manages, cannot benchmarks, and can saturate a Gigabit Ethernet link.
    [Show full text]
  • Towards Predictable Real-Time Performance on Multi-Core Platforms
    Towards Predictable Real-Time Performance on Multi-Core Platforms Submitted in partial fulfillment of the requirements for the degreee of Doctor of Philosophy in Electrical and Computer Engineering Hyoseung Kim B.S., Computer Science, Yonsei University, Seoul, Korea M.S., Computer Science, Yonsei University, Seoul, Korea arXiv:1607.08578v1 [cs.DC] 28 Jul 2016 Carnegie Mellon University Pittsburgh, PA, USA June 2016 Copyright © 2016 Hyoseung Kim Keywords: Cyber-physical systems, Real-time embedded systems, Safety-critical systems, Multi-core platforms, Operating systems, Virtualization, Predictable performance. Abstract Cyber-physical systems (CPS) integrate sensing, computing, communication and actu- ation capabilities to monitor and control operations in the physical environment. A key requirement of such systems is the need to provide predictable real-time performance: the timing correctness of the system should be analyzable at design time with a quantitative metric and guaranteed at runtime with high assurance. This requirement of predictability is particularly important for safety-critical domains such as automobiles, aerospace, defense, manufacturing and medical devices. The work in this dissertation focuses on the challenges arising from the use of modern multi-core platforms in CPS. Even as of today, multi-core platforms are rarely used in safety-critical applications primarily due to the temporal interference caused by contention on various resources shared among processor cores, such as caches, memory buses, and I/O devices. Such interference is hard to predict and can significantly increase task execution time, e.g., up to 12× on commodity quad-core platforms. To address the problem of ensuring timing predictability on multi-core platforms, we develop novel analytical and systems techniques in this dissertation.
    [Show full text]
  • Shared IRQ Line Considerations AN-PM-059
    Application Note Shared IRQ Line Considerations AN-PM-059 Abstract When IRQ line-sharing between multiple devices has been imposed by the target hardware design, a system failure may occur that is intrinsic to the Linux kernel. This document outlines recommendations to avoid such issues. Several solutions have been identified and each should be considered on its merits for the target platform under examination. AN-PM-059 Shared IRQ Line Considerations Contents Abstract ................................................................................................................................................ 1 Contents ............................................................................................................................................... 2 Figures .................................................................................................................................................. 2 1 Terms and Definitions ................................................................................................................... 3 2 References ..................................................................................................................................... 3 3 Introduction.................................................................................................................................... 4 4 Shared Interrupt Line .................................................................................................................... 4 4.1 Symptoms and Mode of Failure in the Linux
    [Show full text]
  • Towards Predictable Real-Time Performance on Multi-Core Platforms
    Towards Predictable Real-Time Performance on Multi-Core Platforms Submitted in partial fulfillment of the requirements for the degreee of Doctor of Philosophy in Electrical and Computer Engineering Hyoseung Kim B.S., Computer Science, Yonsei University, Seoul, Korea M.S., Computer Science, Yonsei University, Seoul, Korea Carnegie Mellon University Pittsburgh, PA, USA June 2016 Copyright © 2016 Hyoseung Kim Keywords: Cyber-physical systems, Real-time embedded systems, Safety-critical systems, Multi-core platforms, Operating systems, Virtualization, Predictable performance. Abstract Cyber-physical systems (CPS) integrate sensing, computing, communication and actu- ation capabilities to monitor and control operations in the physical environment. A key requirement of such systems is the need to provide predictable real-time performance: the timing correctness of the system should be analyzable at design time with a quantitative metric and guaranteed at runtime with high assurance. This requirement of predictability is particularly important for safety-critical domains such as automobiles, aerospace, defense, manufacturing and medical devices. The work in this dissertation focuses on the challenges arising from the use of modern multi-core platforms in CPS. Even as of today, multi-core platforms are rarely used in safety-critical applications primarily due to the temporal interference caused by contention on various resources shared among processor cores, such as caches, memory buses, and I/O devices. Such interference is hard to predict and can significantly increase task execution time, e.g., up to 12× on commodity quad-core platforms. To address the problem of ensuring timing predictability on multi-core platforms, we develop novel analytical and systems techniques in this dissertation.
    [Show full text]
  • Tolerating Malicious Device Drivers in Linux
    Tolerating Malicious Device Drivers in Linux The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Boyd-Wickizer, Silas and Nickolai Zeldovich. "Tolerating Malicious Device Drivers in Linux" USENIX Annual Technical Conference, June 23–25, 2010, Boston, MA, USA. As Published http://www.usenix.org/events/atc10/tech/full_papers/Boyd- Wickizer.pdf Publisher USENIX Association Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/62238 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike 3.0 Detailed Terms http://creativecommons.org/licenses/by-nc-sa/3.0/ Tolerating Malicious Device Drivers in Linux Silas Boyd-Wickizer and Nickolai Zeldovich MIT CSAIL ABSTRACT driver isolation techniques trust the driver not to subvert the isolation, or not to livelock the system. If attackers This paper presents SUD, a system for running existing Linux device drivers as untrusted user-space processes. exploit a bug in the device driver [1, 5], they can proceed Even if the device driver is controlled by a malicious to subvert the isolation mechanism and compromise the adversary, it cannot compromise the rest of the system. entire system. While some systems can provide stronger One significant challenge of fully isolating a driver is to guarantees [28, 33], they rely on the availability of a fully- trusted, precise specification of the hardware device’s confine the actions of its hardware device. SUD relies on IOMMU hardware, PCI express bridges, and message- behavior, which is rarely available for devices today. signaled interrupts to confine hardware devices. SUD This paper presents the design and implementation of runs unmodified Linux device drivers, by emulating a SUD, a kernel framework that provides complete isolation Linux kernel environment in user-space.
    [Show full text]
  • 111I.®@@ , Iw J , J '5 Expected 5 Expected 3 a Return to Timer :Ltimer Firings Normal Mode Duration W '5 L Expected 7 Timer Firings,Y Received 3
    US008533709B2 (12) United States Patent (10) Patent No.: US 8,533,709 B2 Nicholas et al. (45) Date of Patent: Sep. 10, 2013 (54) VIRTUALCHANGINGPROGRAMMABLE MACHINES FREQUENCY INTERRUPT T0 CONTROL OFAVIRTUAL TIMER IN 200336614073232006/0090092 A1 * 4/2006 Verhulstgakdiinentetlai‘if n e ......................a ' "" ~~~~~~~~~~~~ " ~~.. 713/400 VIRTUAL TIME OTHER PUBLICATIONS . Mock et a1. “Continuous clock s chroniZation in Wireless real-time (75) Inventors: Andrew Ernest Nicholas’ Beinevue’ WA applications”, Reliable Distributzid1 Systems, 2000, p. 125-132).* (Us); Rene Anton“) Vega’ Klrkland’ WA Cristian et a1. (“Clock Synchronization in the Presence of Omission (Us) and Performance Failures, and Processor Joins”, IBM Research, 16th IEEE Int. Symp. On Fault-tolerant Computing Systems, Vienna, Jul. (73) Assignee: Microsoft Cororation, Redmond, WA 19g6),* (US) Honeycutt, J., “Microsoft® Virtual PC”, Microsoft®, Nov. 2003, 1-27. ( * ) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 * Cited by examiner U.S.C. 154(b) by 1649 days. Primary Examiner * Meng An (21) Appl. No.1 11/197,614 Assistant Examiner * Eric C Wai (74) Attorney, Agent, or Firm * Woodcock Washburn, LLP (22) Filed: Aug. 4, 2005 (57) ABSTRACT (65) Prior Publication Data . A catch-up mode that runs a v1rtua1 programmable rnterrupt US 2007/0033589 A1 Feb. 8, 2007 timer faster than a nominal rate to prevent time loss in a virtual machine can be implemented. If time loss is determined, a (51) Int- Cl- catch-up mode can be initiated to cause increased ?rings, G06F 9/45 5 (2006-01) beyond a nominal rate, of the programmable interrupt timer to (52) US Cl- adjust the clock of the virtual machine to the clock of the host USPC ...........................................................
    [Show full text]
  • Interrupt Storm Detection" Feature
    Development of "Interrupt Storm Detection" Feature October 2020 Issued by Kento Kobayashi, R&D Center, Sony Corporation Copyright 2020 Sony Corporation Agenda • Background • What is interrupt storm? • Cases of interrupt storms • Existing ways to debug interrupt storms for each cases • Our solution • Interrupt storm detection feature • Example of using interrupt storm detection feature for actual problem 2 26.Oct.2020 R&D Center, Sony Corporation Self introduction • Name • Kento Kobayashi • Company • Sony Corporation • Responsible for • Linux kernel and device drivers for Sony products. 3 26.Oct.2020 R&D Center, Sony Corporation Background 4 26.Oct.2020 R&D Center, Sony Corporation What is “Interrupt Storm”? • “Interrupt Storm” is a continuous hardware interrupt to CPU. • CPU needs to execute interrupt handlers continuously. • “Interrupt Storm” causes: • System hang-up due to high CPU utilization by the interrupt handler • Difficult to debug because console is not responding • To debug interrupt storm: # of Interrupts • Need to identify IRQ number which causes interrupt storm. • Cases of “Interrupt Storm”: • Case1 : Unhandled(Spurious) interrupt • Case2 : High-frequency handled interrupt time 5 26.Oct.2020 R&D Center, Sony Corporation Case1 : Unhandled(Spurious) interrupt • What is “Unhandled(Spurious) interrupt”? • Interrupt handler doesn’t handle hardware interrupt • Why “Unhandled(Spurious) interrupt” occur? • Problem of device driver. • Interrupt handler do nothing if that interrupt is not own interrupt. • Then interrupt status is not clear, so interrupt is raised continuously. • Example of “Unhandled(Spurious) interrupt” case • Shared IRQ by multiple device driver. • Interrupt handler is executed whether not own interrupt. • Then if interrupt handler not recognize as own interrupt wrongly, nobody handled raised interrupt.
    [Show full text]
  • Comparing and Improving Current Packet Capturing Solutions Based on Commodity Hardware
    Comparing and Improving Current Packet Capturing Solutions based on Commodity Hardware Lothar Braun, Alexander Didebulidze, Nils Kammenhuber, Georg Carle Technische Universität München Institute for Informatics Chair for Network Architectures and Services {braun,didebuli,kammenhuber,carle}@net.in.tum.de ABSTRACT tured by Endace [1]—was mandatory for capturing Gigabit Capturing network traffic with commodity hardware has be- or Multi-gigabit network traffic, if little or no packet loss was come a feasible task: Advances in hardware as well as soft- a requirement. With recent development progresses in bus ware have boosted off-the-shelf hardware to performance lev- systems, multi-core CPUs and commodity network cards, els that some years ago were the domain of expensive special- nowadays off-the-shelf hardware can be used to capture net- purpose hardware. However, the capturing hardware still work traffic at near wire-speed with little or no packet loss needs to be driven by a well-performing software stack in in 1 GE networks, too [2, 3]. People are even building mon- order to minimise or avoid packet loss. Improving the cap- itoring devices based on commodity hardware that can be turing stack of Linux and FreeBSD has been an extensively used to capture traffic in 10 GE networks [4, 5] covered research topic in the past years. Although the ma- However, this is not an easy task, since it requires careful jority of the proposed enhancements have been backed by configuration and optimization of the hardware and software evaluations, these have mostly been conducted on different components involved—even the best hardware will suffer hardware platforms and software versions, which renders a packet loss if its driving software stack is not able to handle comparative assessment of the various approaches difficult, the huge amount of network packets.
    [Show full text]