This document discusses interrupts, device drivers, and the xv6 operating system. It provides recaps of previous labs on extraordinary events like interrupts, exceptions, and system calls. It explains how interrupts are handled on multi-processor systems using the I/O APIC to route interrupts and the LAPIC as a per-CPU interrupt controller. An example is given of how timer interrupts are used to track time and scheduling. Device drivers are introduced as code that manages devices by providing interrupt handlers and controlling device operations. The disk driver is given as an example to copy data between disk and memory in 512-byte sectors.
Kernel Recipes 2015: Solving the Linux storage scalability bottlenecksAnne Nicolas
lash devices introduced a sudden shift in the performance profile of direct attached storage. With IOPS rates orders of magnitude higher than rotating storage, it became clear that Linux needed a re-design of its storage stack to properly support and get the most out of these new devices.
This talk will detail the architecture of blk-mq, the redesign of the core of the Linux storage stack, and the later set of changes made to adapt the SCSI stack to this new queuing model. Early results of running Facebook infrastructure production workloads on top of the new stack will also be shared.
Jense Axboe, Facebook
"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." -- Linus Torvalds
From USENIX LISA 2010, San Jose.
Visualizations that include heat maps can be an effective way to present performance data: I/O latency, resource utilization, and more. Patterns can emerge that would be difficult to notice from columns of numbers or line graphs, which are revealing previously unknown behavior. These visualizations are used in a product as a replacement for traditional metrics such as %CPU and are allowing end users to identify more issues much more easily (and some issues are becoming nearly impossible to identify with tools such as vmstat(1)). This talk covers what has been learned, crazy heat map discoveries, and thoughts for future applications beyond performance analysis.
Agenda:
The Linux kernel has multiple "tracers" built-in, with various degrees of support for aggregation, dynamic probes, parameter processing, filtering, histograms, and other features. Starting from the venerable ftrace, introduced in kernel 2.6, all the way through eBPF, which is still under development, there are many options to choose from when you need to statically instrument your software with probes, or diagnose issues in the field using the system's dynamic probes. Modern tools include SystemTap, Sysdig, ktap, perf, bcc, and others. In this talk, we will begin by reviewing the modern tracing landscape -- ftrace, perf_events, kprobes, uprobes, eBPF -- and what insight into system activity these tools can offer. Then, we will look at specific examples of using tracing tools for diagnostics: tracing a memory leak using low-overhead kmalloc/kfree instrumentation, diagnosing a CPU caching issue using perf stat, probing network and block I/O latency distributions under load, or merely snooping user activities by capturing terminal input and output.
Speaker:
Sasha is the CTO of Sela Group, a training and consulting company based in Israel that employs over 400 developers world-wide. Most of Sasha's work revolves around performance optimization, production debugging, and low-level system diagnostics, but he also dabbles in mobile application development on iOS and Android. Sasha is the author of two books and three Pluralsight courses, and a contributor to multiple open-source projects. He blogs at http://blog.sashag.net.
Kernel Recipes 2015: Solving the Linux storage scalability bottlenecksAnne Nicolas
lash devices introduced a sudden shift in the performance profile of direct attached storage. With IOPS rates orders of magnitude higher than rotating storage, it became clear that Linux needed a re-design of its storage stack to properly support and get the most out of these new devices.
This talk will detail the architecture of blk-mq, the redesign of the core of the Linux storage stack, and the later set of changes made to adapt the SCSI stack to this new queuing model. Early results of running Facebook infrastructure production workloads on top of the new stack will also be shared.
Jense Axboe, Facebook
"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." -- Linus Torvalds
From USENIX LISA 2010, San Jose.
Visualizations that include heat maps can be an effective way to present performance data: I/O latency, resource utilization, and more. Patterns can emerge that would be difficult to notice from columns of numbers or line graphs, which are revealing previously unknown behavior. These visualizations are used in a product as a replacement for traditional metrics such as %CPU and are allowing end users to identify more issues much more easily (and some issues are becoming nearly impossible to identify with tools such as vmstat(1)). This talk covers what has been learned, crazy heat map discoveries, and thoughts for future applications beyond performance analysis.
Agenda:
The Linux kernel has multiple "tracers" built-in, with various degrees of support for aggregation, dynamic probes, parameter processing, filtering, histograms, and other features. Starting from the venerable ftrace, introduced in kernel 2.6, all the way through eBPF, which is still under development, there are many options to choose from when you need to statically instrument your software with probes, or diagnose issues in the field using the system's dynamic probes. Modern tools include SystemTap, Sysdig, ktap, perf, bcc, and others. In this talk, we will begin by reviewing the modern tracing landscape -- ftrace, perf_events, kprobes, uprobes, eBPF -- and what insight into system activity these tools can offer. Then, we will look at specific examples of using tracing tools for diagnostics: tracing a memory leak using low-overhead kmalloc/kfree instrumentation, diagnosing a CPU caching issue using perf stat, probing network and block I/O latency distributions under load, or merely snooping user activities by capturing terminal input and output.
Speaker:
Sasha is the CTO of Sela Group, a training and consulting company based in Israel that employs over 400 developers world-wide. Most of Sasha's work revolves around performance optimization, production debugging, and low-level system diagnostics, but he also dabbles in mobile application development on iOS and Android. Sasha is the author of two books and three Pluralsight courses, and a contributor to multiple open-source projects. He blogs at http://blog.sashag.net.
Kernel Recipes 2015: Kernel packet capture technologiesAnne Nicolas
Sniffing through the ages
Capturing packets running on the wire to send them to a software doing analysis seems at first sight a simple tasks. But one has not to forget that with current network this can means capturing 30M packets per second. The objective of this talk is to show what methods and techniques have been implemented in Linux and how they have evolved over time.
The talk will cover AF_PACKET capture as well as PF_RING, dpdk and netmap. It will try to show how the various evolution of hardware and software have had an impact on the design of these technologies. Regarding software a special focus will be made on Suricata IDS which is implementing most of these capture methods.
Eric Leblond, Stamus Networks
Broken benchmarks, misleading metrics, and terrible tools. This talk will help you navigate the treacherous waters of Linux performance tools, touring common problems with system tools, metrics, statistics, visualizations, measurement overhead, and benchmarks. You might discover that tools you have been using for years, are in fact, misleading, dangerous, or broken.
The speaker, Brendan Gregg, has given many talks on tools that work, including giving the Linux PerformanceTools talk originally at SCALE. This is an anti-version of that talk, to focus on broken tools and metrics instead of the working ones. Metrics can be misleading, and counters can be counter-intuitive! This talk will include advice for verifying new performance tools, understanding how they work, and using them successfully.
Video: https://www.youtube.com/watch?v=JRFNIKUROPE . Talk for linux.conf.au 2017 (LCA2017) by Brendan Gregg, about Linux enhanced BPF (eBPF). Abstract:
A world of new capabilities is emerging for the Linux 4.x series, thanks to enhancements that have been included in Linux for to Berkeley Packet Filter (BPF): an in-kernel virtual machine that can execute user space-defined programs. It is finding uses for security auditing and enforcement, enhancing networking (including eXpress Data Path), and performance observability and troubleshooting. Many new open source tools that have been written in the past 12 months for performance analysis that use BPF. Tracing superpowers have finally arrived for Linux!
For its use with tracing, BPF provides the programmable capabilities to the existing tracing frameworks: kprobes, uprobes, and tracepoints. In particular, BPF allows timestamps to be recorded and compared from custom events, allowing latency to be studied in many new places: kernel and application internals. It also allows data to be efficiently summarized in-kernel, including as histograms. This has allowed dozens of new observability tools to be developed so far, including measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more.
This talk will summarize BPF capabilities and use cases so far, and then focus on its use to enhance Linux tracing, especially with the open source bcc collection. bcc includes BPF versions of old classics, and many new tools, including execsnoop, opensnoop, funcccount, ext4slower, and more (many of which I developed). Perhaps you'd like to develop new tools, or use the existing tools to find performance wins large and small, especially when instrumenting areas that previously had zero visibility. I'll also summarize how we intend to use these new capabilities to enhance systems analysis at Netflix.
In this talk Liran will discuss interrupt management in Linux, effective handling, how to defer work using tasklets, workqueues and timers. We'll learn how to handle interrupts in userspace and talk about the performance and latency aspects of each method as well as look at some examples from the kernel source.
Liran is the CTO at Mabel technology and co-founder of DiscoverSDK - Software Libraries directory and DiscoverCloud - Business Apps directory.
More than 20 years of training experience including courses in: Linux, Android, Real-time and Embedded systems, and many more.
Kernel Recipes 2015 - So you want to write a Linux driver frameworkAnne Nicolas
Writing a new driver framework in Linux is hard. There are many pitfalls along the way; this talk hopes to point out some of those pitfalls and hard lessons learned through examples, advice and humorous anecdotes in the hope that it will aid those adventurous enough to take on the task of writing a new driver framework. The scope of the talk includes internal framework design as well as external API design exposed to drivers and consumers of the framework. This presentation pulls directly from the Michael Turquette’s experience authoring the Common Clock
Framework and maintaining that code for the last four years.
Additionally Mike has solicited tips and advice from other subsystem maintainers, for a well-rounded overview. Be prepared to learn some winning design patterns and hear some embarrassing stories of framework design gone wrong.
Mike Turquette, BayLibre
This talk is about a new interface to get information about processes, called task_diag, which we developed.
Currently /proc file system is used to get information about the processes running on the system. All information are presented as text files, which is convenient for humans, but not for programs such as ps and top. This incurs significant delays, especially on a systems with lots of containers running, which is frequently the case nowdays.
Ideally, tools such top and ps would get information in binary format, and use flexible means to specify which kinds of information and for which tasks is required. Presented is a new interface with all these features, called task_diag.
task_diag is based on netlink sockets and looks like socket-diag, which is used to get information about sockets. It uses the request-response model. An request specifies a set of processes and required properties for them. A response contains requested information and can be divided into a few netlink packets if it's too long.
The task diag is much faster than the /proc file system. For example, when reading from /proc, ps opens, reads, and closes many files -- and iterates this for every single processes. With task_diag, it's just sending a request and getting a response.
Except for ps and top, the proposed interface is to be used by CRIU, a containers checkpoint/restore and live migration mechanism. Also, developers of perf tool found that it can be useful to them and implemented a prototype which show a big performance improvements in case of using task_diag instead of procfs.
Our performance measurements show that the ps tool works at least four times faster if task_diag is used instead of procfs.
Talk for PerconaLive 2016 by Brendan Gregg. Video: https://www.youtube.com/watch?v=CbmEDXq7es0 . "Systems performance provides a different perspective for analysis and tuning, and can help you find performance wins for your databases, applications, and the kernel. However, most of us are not performance or kernel engineers, and have limited time to study this topic. This talk summarizes six important areas of Linux systems performance in 50 minutes: observability tools, methodologies, benchmarking, profiling, tracing, and tuning. Included are recipes for Linux performance analysis and tuning (using vmstat, mpstat, iostat, etc), overviews of complex areas including profiling (perf_events), static tracing (tracepoints), and dynamic tracing (kprobes, uprobes), and much advice about what is and isn't important to learn. This talk is aimed at everyone: DBAs, developers, operations, etc, and in any environment running Linux, bare-metal or the cloud."
EuroBSDcon 2017 System Performance Analysis MethodologiesBrendan Gregg
keynote by Brendan Gregg. "Traditional performance monitoring makes do with vendor-supplied metrics, often involving interpretation and inference, and with numerous blind spots. Much in the field of systems performance is still living in the past: documentation, procedures, and analysis GUIs built upon the same old metrics. Modern BSD has advanced tracers and PMC tools, providing virtually endless metrics to aid performance analysis. It's time we really used them, but the problem becomes which metrics to use, and how to navigate them quickly to locate the root cause of problems.
There's a new way to approach performance analysis that can guide you through the metrics. Instead of starting with traditional metrics and figuring out their use, you start with the questions you want answered then look for metrics to answer them. Methodologies can provide these questions, as well as a starting point for analysis and guidance for locating the root cause. They also pose questions that the existing metrics may not yet answer, which may be critical in solving the toughest problems. System methodologies include the USE method, workload characterization, drill-down analysis, off-CPU analysis, chain graphs, and more.
This talk will discuss various system performance issues, and the methodologies, tools, and processes used to solve them. Many methodologies will be discussed, from the production proven to the cutting edge, along with recommendations for their implementation on BSD systems. In general, you will learn to think differently about analyzing your systems, and make better use of the modern tools that BSD provides."
Systems Performance: Enterprise and the CloudBrendan Gregg
My talk for BayLISA, Oct 2013, launching the Systems Performance book. Operating system performance analysis and tuning leads to a better end-user experience and lower costs, especially for cloud computing environments that pay by the operating system instance. This book covers concepts, strategy, tools and tuning for Unix operating systems, with a focus on Linux- and Solaris-based systems. The book covers the latest tools and techniques, including static and dynamic tracing, to get the most out of your systems.
Video: https://www.facebook.com/atscaleevents/videos/1693888610884236/ . Talk by Brendan Gregg from Facebook's Performance @Scale: "Linux performance analysis has been the domain of ancient tools and metrics, but that's now changing in the Linux 4.x series. A new tracer is available in the mainline kernel, built from dynamic tracing (kprobes, uprobes) and enhanced BPF (Berkeley Packet Filter), aka, eBPF. It allows us to measure latency distributions for file system I/O and run queue latency, print details of storage device I/O and TCP retransmits, investigate blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. This talk will summarize this new technology and some long-standing issues that it can solve, and how we intend to use it at Netflix."
A brief talk on systems performance for the July 2013 meetup "A Midsummer Night's System", video: http://www.youtube.com/watch?v=P3SGzykDE4Q. This summarizes how systems performance has changed from the 1990's to today. This was the reason for writing a new book on systems performance, to provide a reference that is up to date, covering new tools, technologies, and methodologies.
Embedded Recipes 2018 - Finding sources of Latency In your system - Steven Ro...Anne Nicolas
Having just an RTOS is not enough for a real-time system. The hardware must be deterministic as well as the applications that run on the system. When you are missing deadlines, the first thing that must be done is to find what is the source of the latency that caused the issue. It could be the hardware, the operating system or the application, or even a combination of the above. This talk will discuss how to determine where the latency is using tools that come with the Linux Kernel, and will explain a few cases that caused issues.
Agenda:
This talk will provide an in-depth review of the usage of canaries in the kernel and the interaction with userspace, as well as a short review of canaries and why they are needed in general so don't be afraid if you never heard of them.
Speaker:
Gil Yankovitch, CEO, Chief Security Researcher from Nyx Security Solutions
This presentation covers the general concepts about real-time systems, how Linux kernel works for preemption, the latency in Linux, rt-preempt, and Xenomai, the real-time extension as the dual kernel approach.
Kernel Recipes 2015: Kernel packet capture technologiesAnne Nicolas
Sniffing through the ages
Capturing packets running on the wire to send them to a software doing analysis seems at first sight a simple tasks. But one has not to forget that with current network this can means capturing 30M packets per second. The objective of this talk is to show what methods and techniques have been implemented in Linux and how they have evolved over time.
The talk will cover AF_PACKET capture as well as PF_RING, dpdk and netmap. It will try to show how the various evolution of hardware and software have had an impact on the design of these technologies. Regarding software a special focus will be made on Suricata IDS which is implementing most of these capture methods.
Eric Leblond, Stamus Networks
Broken benchmarks, misleading metrics, and terrible tools. This talk will help you navigate the treacherous waters of Linux performance tools, touring common problems with system tools, metrics, statistics, visualizations, measurement overhead, and benchmarks. You might discover that tools you have been using for years, are in fact, misleading, dangerous, or broken.
The speaker, Brendan Gregg, has given many talks on tools that work, including giving the Linux PerformanceTools talk originally at SCALE. This is an anti-version of that talk, to focus on broken tools and metrics instead of the working ones. Metrics can be misleading, and counters can be counter-intuitive! This talk will include advice for verifying new performance tools, understanding how they work, and using them successfully.
Video: https://www.youtube.com/watch?v=JRFNIKUROPE . Talk for linux.conf.au 2017 (LCA2017) by Brendan Gregg, about Linux enhanced BPF (eBPF). Abstract:
A world of new capabilities is emerging for the Linux 4.x series, thanks to enhancements that have been included in Linux for to Berkeley Packet Filter (BPF): an in-kernel virtual machine that can execute user space-defined programs. It is finding uses for security auditing and enforcement, enhancing networking (including eXpress Data Path), and performance observability and troubleshooting. Many new open source tools that have been written in the past 12 months for performance analysis that use BPF. Tracing superpowers have finally arrived for Linux!
For its use with tracing, BPF provides the programmable capabilities to the existing tracing frameworks: kprobes, uprobes, and tracepoints. In particular, BPF allows timestamps to be recorded and compared from custom events, allowing latency to be studied in many new places: kernel and application internals. It also allows data to be efficiently summarized in-kernel, including as histograms. This has allowed dozens of new observability tools to be developed so far, including measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more.
This talk will summarize BPF capabilities and use cases so far, and then focus on its use to enhance Linux tracing, especially with the open source bcc collection. bcc includes BPF versions of old classics, and many new tools, including execsnoop, opensnoop, funcccount, ext4slower, and more (many of which I developed). Perhaps you'd like to develop new tools, or use the existing tools to find performance wins large and small, especially when instrumenting areas that previously had zero visibility. I'll also summarize how we intend to use these new capabilities to enhance systems analysis at Netflix.
In this talk Liran will discuss interrupt management in Linux, effective handling, how to defer work using tasklets, workqueues and timers. We'll learn how to handle interrupts in userspace and talk about the performance and latency aspects of each method as well as look at some examples from the kernel source.
Liran is the CTO at Mabel technology and co-founder of DiscoverSDK - Software Libraries directory and DiscoverCloud - Business Apps directory.
More than 20 years of training experience including courses in: Linux, Android, Real-time and Embedded systems, and many more.
Kernel Recipes 2015 - So you want to write a Linux driver frameworkAnne Nicolas
Writing a new driver framework in Linux is hard. There are many pitfalls along the way; this talk hopes to point out some of those pitfalls and hard lessons learned through examples, advice and humorous anecdotes in the hope that it will aid those adventurous enough to take on the task of writing a new driver framework. The scope of the talk includes internal framework design as well as external API design exposed to drivers and consumers of the framework. This presentation pulls directly from the Michael Turquette’s experience authoring the Common Clock
Framework and maintaining that code for the last four years.
Additionally Mike has solicited tips and advice from other subsystem maintainers, for a well-rounded overview. Be prepared to learn some winning design patterns and hear some embarrassing stories of framework design gone wrong.
Mike Turquette, BayLibre
This talk is about a new interface to get information about processes, called task_diag, which we developed.
Currently /proc file system is used to get information about the processes running on the system. All information are presented as text files, which is convenient for humans, but not for programs such as ps and top. This incurs significant delays, especially on a systems with lots of containers running, which is frequently the case nowdays.
Ideally, tools such top and ps would get information in binary format, and use flexible means to specify which kinds of information and for which tasks is required. Presented is a new interface with all these features, called task_diag.
task_diag is based on netlink sockets and looks like socket-diag, which is used to get information about sockets. It uses the request-response model. An request specifies a set of processes and required properties for them. A response contains requested information and can be divided into a few netlink packets if it's too long.
The task diag is much faster than the /proc file system. For example, when reading from /proc, ps opens, reads, and closes many files -- and iterates this for every single processes. With task_diag, it's just sending a request and getting a response.
Except for ps and top, the proposed interface is to be used by CRIU, a containers checkpoint/restore and live migration mechanism. Also, developers of perf tool found that it can be useful to them and implemented a prototype which show a big performance improvements in case of using task_diag instead of procfs.
Our performance measurements show that the ps tool works at least four times faster if task_diag is used instead of procfs.
Talk for PerconaLive 2016 by Brendan Gregg. Video: https://www.youtube.com/watch?v=CbmEDXq7es0 . "Systems performance provides a different perspective for analysis and tuning, and can help you find performance wins for your databases, applications, and the kernel. However, most of us are not performance or kernel engineers, and have limited time to study this topic. This talk summarizes six important areas of Linux systems performance in 50 minutes: observability tools, methodologies, benchmarking, profiling, tracing, and tuning. Included are recipes for Linux performance analysis and tuning (using vmstat, mpstat, iostat, etc), overviews of complex areas including profiling (perf_events), static tracing (tracepoints), and dynamic tracing (kprobes, uprobes), and much advice about what is and isn't important to learn. This talk is aimed at everyone: DBAs, developers, operations, etc, and in any environment running Linux, bare-metal or the cloud."
EuroBSDcon 2017 System Performance Analysis MethodologiesBrendan Gregg
keynote by Brendan Gregg. "Traditional performance monitoring makes do with vendor-supplied metrics, often involving interpretation and inference, and with numerous blind spots. Much in the field of systems performance is still living in the past: documentation, procedures, and analysis GUIs built upon the same old metrics. Modern BSD has advanced tracers and PMC tools, providing virtually endless metrics to aid performance analysis. It's time we really used them, but the problem becomes which metrics to use, and how to navigate them quickly to locate the root cause of problems.
There's a new way to approach performance analysis that can guide you through the metrics. Instead of starting with traditional metrics and figuring out their use, you start with the questions you want answered then look for metrics to answer them. Methodologies can provide these questions, as well as a starting point for analysis and guidance for locating the root cause. They also pose questions that the existing metrics may not yet answer, which may be critical in solving the toughest problems. System methodologies include the USE method, workload characterization, drill-down analysis, off-CPU analysis, chain graphs, and more.
This talk will discuss various system performance issues, and the methodologies, tools, and processes used to solve them. Many methodologies will be discussed, from the production proven to the cutting edge, along with recommendations for their implementation on BSD systems. In general, you will learn to think differently about analyzing your systems, and make better use of the modern tools that BSD provides."
Systems Performance: Enterprise and the CloudBrendan Gregg
My talk for BayLISA, Oct 2013, launching the Systems Performance book. Operating system performance analysis and tuning leads to a better end-user experience and lower costs, especially for cloud computing environments that pay by the operating system instance. This book covers concepts, strategy, tools and tuning for Unix operating systems, with a focus on Linux- and Solaris-based systems. The book covers the latest tools and techniques, including static and dynamic tracing, to get the most out of your systems.
Video: https://www.facebook.com/atscaleevents/videos/1693888610884236/ . Talk by Brendan Gregg from Facebook's Performance @Scale: "Linux performance analysis has been the domain of ancient tools and metrics, but that's now changing in the Linux 4.x series. A new tracer is available in the mainline kernel, built from dynamic tracing (kprobes, uprobes) and enhanced BPF (Berkeley Packet Filter), aka, eBPF. It allows us to measure latency distributions for file system I/O and run queue latency, print details of storage device I/O and TCP retransmits, investigate blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. This talk will summarize this new technology and some long-standing issues that it can solve, and how we intend to use it at Netflix."
A brief talk on systems performance for the July 2013 meetup "A Midsummer Night's System", video: http://www.youtube.com/watch?v=P3SGzykDE4Q. This summarizes how systems performance has changed from the 1990's to today. This was the reason for writing a new book on systems performance, to provide a reference that is up to date, covering new tools, technologies, and methodologies.
Embedded Recipes 2018 - Finding sources of Latency In your system - Steven Ro...Anne Nicolas
Having just an RTOS is not enough for a real-time system. The hardware must be deterministic as well as the applications that run on the system. When you are missing deadlines, the first thing that must be done is to find what is the source of the latency that caused the issue. It could be the hardware, the operating system or the application, or even a combination of the above. This talk will discuss how to determine where the latency is using tools that come with the Linux Kernel, and will explain a few cases that caused issues.
Agenda:
This talk will provide an in-depth review of the usage of canaries in the kernel and the interaction with userspace, as well as a short review of canaries and why they are needed in general so don't be afraid if you never heard of them.
Speaker:
Gil Yankovitch, CEO, Chief Security Researcher from Nyx Security Solutions
This presentation covers the general concepts about real-time systems, how Linux kernel works for preemption, the latency in Linux, rt-preempt, and Xenomai, the real-time extension as the dual kernel approach.
These slides were presented during technical event at my organization. It focuses on overview to find a root cause of the unexpected system down events. It is mainly useful for Linux or Unix system administrators. Here, I tried to cover all aspects of the topic. It took me more than 2 hours to present these slides, but one can also cover these slides within short time-span. Gray background of slides is implemented to hide the company logo and to preserve the confidentially of private template. However, The Knowledge is not restricted :)
A short, introductory talk to the world of debuggers. During the talk, we write a simple debugger application in Rust.
Video at: https://www.youtube.com/watch?v=qS51kIHWARM
The objectives of Multithreaded Programming in Operating Systems are:
- To introduce the notion of a thread—a fundamental unit of CPU utilization that forms the basis of multithreaded computer systems.
- To discuss the APIs for the Pthreads, Windows, and Java thread libraries
- To explore several strategies that provide implicit threading.
- To examine issues related to multithreaded programming.
- To cover operating system support for threads in Windows and Linux.
OS | Functions of OS | Operations of OS | Operations of a process | Scheduling algorithms | FCFS scheduling | SJF scheduling | RR scheduling | Paging | File system implementation | Cryptography as a security tool
Automating the Hunt for Non-Obvious Sources of Latency SpreadsScyllaDB
False sharing references and power management can trigger wide latency spreads, but are neither directly observable nor easily traced to causes. This talk describes how to diagnose the problems quickly, and outlines several remedies.
Similar to AOS Lab 8: Interrupts and Device Drivers (20)
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Monitoring Java Application Security with JDK Tools and JFR Events
AOS Lab 8: Interrupts and Device Drivers
1. Lab 8: Interrupts and Device Drivers
Advanced Operating Systems
Zubair Nabi
zubair.nabi@itu.edu.pk
March 28, 2013
2. Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to the
kernel:
1
A device signals that it needs attention (e.g. Timer): Interrupt
2
A user program does something illegal (e.g. divide by zero):
Exception
3
A user program asks the kernel for a service: System call
3. Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to the
kernel:
1
A device signals that it needs attention (e.g. Timer): Interrupt
2
A user program does something illegal (e.g. divide by zero):
Exception
3
A user program asks the kernel for a service: System call
4. Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to the
kernel:
1
A device signals that it needs attention (e.g. Timer): Interrupt
2
A user program does something illegal (e.g. divide by zero):
Exception
3
A user program asks the kernel for a service: System call
5. Recap of Lab 5: Extraordinary events
Events that break normal processor flow, to return control to the
kernel:
1
A device signals that it needs attention (e.g. Timer): Interrupt
2
A user program does something illegal (e.g. divide by zero):
Exception
3
A user program asks the kernel for a service: System call
6. Recap of Lab 5: Handling extraordinary events
The operating system must:
1
Save the processor’s registers for future resumption
2
Set up system for execution in the kernel
3
Choose a place for the kernel to start execution
4
Retrieve information about the event and call corresponding
interrupt handler
5
All the while, maintain isolation between user processes and the
kernel
7. Recap of Lab 5: Handling extraordinary events
The operating system must:
1
Save the processor’s registers for future resumption
2
Set up system for execution in the kernel
3
Choose a place for the kernel to start execution
4
Retrieve information about the event and call corresponding
interrupt handler
5
All the while, maintain isolation between user processes and the
kernel
8. Recap of Lab 5: Handling extraordinary events
The operating system must:
1
Save the processor’s registers for future resumption
2
Set up system for execution in the kernel
3
Choose a place for the kernel to start execution
4
Retrieve information about the event and call corresponding
interrupt handler
5
All the while, maintain isolation between user processes and the
kernel
9. Recap of Lab 5: Handling extraordinary events
The operating system must:
1
Save the processor’s registers for future resumption
2
Set up system for execution in the kernel
3
Choose a place for the kernel to start execution
4
Retrieve information about the event and call corresponding
interrupt handler
5
All the while, maintain isolation between user processes and the
kernel
10. Recap of Lab 5: Handling extraordinary events
The operating system must:
1
Save the processor’s registers for future resumption
2
Set up system for execution in the kernel
3
Choose a place for the kernel to start execution
4
Retrieve information about the event and call corresponding
interrupt handler
5
All the while, maintain isolation between user processes and the
kernel
11. Recap of Lab 5: Handling extraordinary events
The operating system must:
1
Save the processor’s registers for future resumption
2
Set up system for execution in the kernel
3
Choose a place for the kernel to start execution
4
Retrieve information about the event and call corresponding
interrupt handler
5
All the while, maintain isolation between user processes and the
kernel
12. Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the int
instruction
• The same mechanism for handling interrupts is used for handling
system calls and exceptions
• Traps are caused by the current running process
• Interrupts are caused by devices
• Can happen concurrently
13. Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the int
instruction
• The same mechanism for handling interrupts is used for handling
system calls and exceptions
• Traps are caused by the current running process
• Interrupts are caused by devices
• Can happen concurrently
14. Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the int
instruction
• The same mechanism for handling interrupts is used for handling
system calls and exceptions
• Traps are caused by the current running process
• Interrupts are caused by devices
• Can happen concurrently
15. Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the int
instruction
• The same mechanism for handling interrupts is used for handling
system calls and exceptions
• Traps are caused by the current running process
• Interrupts are caused by devices
• Can happen concurrently
16. Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the int
instruction
• The same mechanism for handling interrupts is used for handling
system calls and exceptions
• Traps are caused by the current running process
• Interrupts are caused by devices
• Can happen concurrently
17. Recap of Lab 5: Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the int
instruction
• The same mechanism for handling interrupts is used for handling
system calls and exceptions
• Traps are caused by the current running process
• Interrupts are caused by devices
• Can happen concurrently
18. Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call
(T_SYSCALL) or a hardware interrupt or an exception
• In case of:
1 System call, it invokes syscall
2
3
Hardware interrupt, it calls the hardware interrupt controller
Exception, it prints the details and kills the user process
19. Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call
(T_SYSCALL) or a hardware interrupt or an exception
• In case of:
1 System call, it invokes syscall
2
3
Hardware interrupt, it calls the hardware interrupt controller
Exception, it prints the details and kills the user process
20. Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call
(T_SYSCALL) or a hardware interrupt or an exception
• In case of:
1 System call, it invokes syscall
2
3
Hardware interrupt, it calls the hardware interrupt controller
Exception, it prints the details and kills the user process
21. Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call
(T_SYSCALL) or a hardware interrupt or an exception
• In case of:
1 System call, it invokes syscall
2
3
Hardware interrupt, it calls the hardware interrupt controller
Exception, it prints the details and kills the user process
22. Recap of Lab 5: trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call
(T_SYSCALL) or a hardware interrupt or an exception
• In case of:
1 System call, it invokes syscall
2
3
Hardware interrupt, it calls the hardware interrupt controller
Exception, it prints the details and kills the user process
23. Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storing
data on disk etc.
• Hardware on the motherboard signals the CPU whenever a
device needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
24. Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storing
data on disk etc.
• Hardware on the motherboard signals the CPU whenever a
device needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
25. Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storing
data on disk etc.
• Hardware on the motherboard signals the CPU whenever a
device needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
26. Interrupts
• Examples of interrupts: Pressing a key on the keyboard, storing
data on disk etc.
• Hardware on the motherboard signals the CPU whenever a
device needs attention
• Devices need to be programmed to generate interrupts
• Interrupts must be assigned to a CPU for handling
27. Handing interrupts on multi-processors
Two parts of handling interrupts on multi-processors
1
A method to route interrupts to processors (I/O APIC – Advanced
Programmable Interrupt Controller, ioapic.c)
2
A per CPU interrupt controller to handle interrupts (Local APIC,
lapic.c)
The OS needs to program both the IOAPIC and the LAPIC
28. Handing interrupts on multi-processors
Two parts of handling interrupts on multi-processors
1
A method to route interrupts to processors (I/O APIC – Advanced
Programmable Interrupt Controller, ioapic.c)
2
A per CPU interrupt controller to handle interrupts (Local APIC,
lapic.c)
The OS needs to program both the IOAPIC and the LAPIC
29. Handing interrupts on multi-processors
Two parts of handling interrupts on multi-processors
1
A method to route interrupts to processors (I/O APIC – Advanced
Programmable Interrupt Controller, ioapic.c)
2
A per CPU interrupt controller to handle interrupts (Local APIC,
lapic.c)
The OS needs to program both the IOAPIC and the LAPIC
30. IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 to
IRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table and
specifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while disk
interrupts are routed to CPU(n − 1), where n is the number of
CPUs
• Every CPU decides whether it wants to receive interrupts. For
instance, scheduler() disables all interrupts
31. IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 to
IRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table and
specifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while disk
interrupts are routed to CPU(n − 1), where n is the number of
CPUs
• Every CPU decides whether it wants to receive interrupts. For
instance, scheduler() disables all interrupts
32. IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 to
IRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table and
specifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while disk
interrupts are routed to CPU(n − 1), where n is the number of
CPUs
• Every CPU decides whether it wants to receive interrupts. For
instance, scheduler() disables all interrupts
33. IOAPIC
• Interrupts are generated by the APIC labelled from IRQ0 to
IRQ16 or IRQ24
• A device enables particular interrupts within the IOAPIC table and
specifies which processor they should be routed to
• For instance, the keyboard interrupt is routed to CPU0 while disk
interrupts are routed to CPU(n − 1), where n is the number of
CPUs
• Every CPU decides whether it wants to receive interrupts. For
instance, scheduler() disables all interrupts
34. LAPIC
• Each CPU has its own LAPIC
• xv6 programs the LAPIC using lapicinit()
35. LAPIC
• Each CPU has its own LAPIC
• xv6 programs the LAPIC using lapicinit()
36. Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and to
make scheduling decisions
• A value of 100 timer ticks is used by default which is high enough
to allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mapped
to IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incremented
and processes sleeping on it are woken up
37. Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and to
make scheduling decisions
• A value of 100 timer ticks is used by default which is high enough
to allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mapped
to IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incremented
and processes sleeping on it are woken up
38. Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and to
make scheduling decisions
• A value of 100 timer ticks is used by default which is high enough
to allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mapped
to IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incremented
and processes sleeping on it are woken up
39. Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and to
make scheduling decisions
• A value of 100 timer ticks is used by default which is high enough
to allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mapped
to IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incremented
and processes sleeping on it are woken up
40. Example: Timer interrupt
• The kernel uses timer interrupts to get a notion of time and to
make scheduling decisions
• A value of 100 timer ticks is used by default which is high enough
to allow interactivity and low enough not to lead to a live lock
• This value is set in lapicinit() and IRQ_TIMER is mapped
to IRQ0
• IRQ_TIMER corresponds to interrupt number 32
• In trap(), for interrupt number 32, the timer tick is incremented
and processes sleeping on it are woken up
41. Device Driver
• A piece of code in the OS that manages a particular device
• Provides interrupt handlers for a device
• Causes a device to perform operations
• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with the
device that it manages
• Driver also needs to understand the hardware interface of the
device
42. Device Driver
• A piece of code in the OS that manages a particular device
• Provides interrupt handlers for a device
• Causes a device to perform operations
• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with the
device that it manages
• Driver also needs to understand the hardware interface of the
device
43. Device Driver
• A piece of code in the OS that manages a particular device
• Provides interrupt handlers for a device
• Causes a device to perform operations
• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with the
device that it manages
• Driver also needs to understand the hardware interface of the
device
44. Device Driver
• A piece of code in the OS that manages a particular device
• Provides interrupt handlers for a device
• Causes a device to perform operations
• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with the
device that it manages
• Driver also needs to understand the hardware interface of the
device
45. Device Driver
• A piece of code in the OS that manages a particular device
• Provides interrupt handlers for a device
• Causes a device to perform operations
• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with the
device that it manages
• Driver also needs to understand the hardware interface of the
device
46. Device Driver
• A piece of code in the OS that manages a particular device
• Provides interrupt handlers for a device
• Causes a device to perform operations
• Causes a device to generate interrupts
• Non-trivial to write as a driver executes concurrently with the
device that it manages
• Driver also needs to understand the hardware interface of the
device
47. Example: Disk driver
• In charge of copying data back and forth from the disk
• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks
• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) that
maps to one sector
• The data within the OS sector structure is often out of sync with
the disk
• xv6 implements an IDE driver
48. Example: Disk driver
• In charge of copying data back and forth from the disk
• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks
• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) that
maps to one sector
• The data within the OS sector structure is often out of sync with
the disk
• xv6 implements an IDE driver
49. Example: Disk driver
• In charge of copying data back and forth from the disk
• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks
• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) that
maps to one sector
• The data within the OS sector structure is often out of sync with
the disk
• xv6 implements an IDE driver
50. Example: Disk driver
• In charge of copying data back and forth from the disk
• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks
• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) that
maps to one sector
• The data within the OS sector structure is often out of sync with
the disk
• xv6 implements an IDE driver
51. Example: Disk driver
• In charge of copying data back and forth from the disk
• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks
• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) that
maps to one sector
• The data within the OS sector structure is often out of sync with
the disk
• xv6 implements an IDE driver
52. Example: Disk driver
• In charge of copying data back and forth from the disk
• Data is represented on the disk as a sequence of sectors, each
containing 512-byte blocks
• Sector 0 represents the first 512 bytes, sector 1 the next 512, and
so on
• The OS has a corresponding structure (struct buf) that
maps to one sector
• The data within the OS sector structure is often out of sync with
the disk
• xv6 implements an IDE driver
54. Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the disk
driver
1 ideinit() sets up CPU(n − 1) to handle disk interrupts
2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loader
and the kernel were obviously loaded from it
3
idewait() polls the status bits of the disk hardware, until
IDE_BSY is clear and IDE_DRDY is set
4
It then checks whether another disk is present
55. Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the disk
driver
1 ideinit() sets up CPU(n − 1) to handle disk interrupts
2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loader
and the kernel were obviously loaded from it
3
idewait() polls the status bits of the disk hardware, until
IDE_BSY is clear and IDE_DRDY is set
4
It then checks whether another disk is present
56. Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the disk
driver
1 ideinit() sets up CPU(n − 1) to handle disk interrupts
2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loader
and the kernel were obviously loaded from it
3
idewait() polls the status bits of the disk hardware, until
IDE_BSY is clear and IDE_DRDY is set
4
It then checks whether another disk is present
57. Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the disk
driver
1 ideinit() sets up CPU(n − 1) to handle disk interrupts
2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loader
and the kernel were obviously loaded from it
3
idewait() polls the status bits of the disk hardware, until
IDE_BSY is clear and IDE_DRDY is set
4
It then checks whether another disk is present
58. Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the disk
driver
1 ideinit() sets up CPU(n − 1) to handle disk interrupts
2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loader
and the kernel were obviously loaded from it
3
idewait() polls the status bits of the disk hardware, until
IDE_BSY is clear and IDE_DRDY is set
4
It then checks whether another disk is present
59. Example: Disk driver initialization
• ideinit() is invoked by main(), which initializes the disk
driver
1 ideinit() sets up CPU(n − 1) to handle disk interrupts
2 It then makes a call to idewait() to wait for disk 0 to initialize
• It assumes that at least disk 0 is present because the boot loader
and the kernel were obviously loaded from it
3
idewait() polls the status bits of the disk hardware, until
IDE_BSY is clear and IDE_DRDY is set
4
It then checks whether another disk is present
60. Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks
• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk
• If B_DIRTY is set, it writes b to disk
• If B_VALID is not set, it reads b from disk
61. Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks
• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk
• If B_DIRTY is set, it writes b to disk
• If B_VALID is not set, it reads b from disk
62. Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks
• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk
• If B_DIRTY is set, it writes b to disk
• If B_VALID is not set, it reads b from disk
63. Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks
• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk
• If B_DIRTY is set, it writes b to disk
• If B_VALID is not set, it reads b from disk
64. Buffer cache
• The buffer cache is a linked list of struct buf in memory
• It holds cached copies of disk blocks
• Uses iderw(struct buf *b) to read/write a buffer from/to
the disk
• If B_DIRTY is set, it writes b to disk
• If B_VALID is not set, it reads b from disk
65. iderw
• Disk accesses take milliseconds of time therefore polling is not an
option
• iderw keeps the list of pending disk requests in a queue
(idequeue) and uses interrupts to signal whenever a request
has finished
• It adds b to the end of idequeue
• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues a
read or a write
• The current process is then put to sleep waiting for the operation
on b to be completed
• Once the hardware has completed the operation, it will generate
an interrupt (IRQ_IDE) which will be handled by trap by
invoking ideintr()
66. iderw
• Disk accesses take milliseconds of time therefore polling is not an
option
• iderw keeps the list of pending disk requests in a queue
(idequeue) and uses interrupts to signal whenever a request
has finished
• It adds b to the end of idequeue
• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues a
read or a write
• The current process is then put to sleep waiting for the operation
on b to be completed
• Once the hardware has completed the operation, it will generate
an interrupt (IRQ_IDE) which will be handled by trap by
invoking ideintr()
67. iderw
• Disk accesses take milliseconds of time therefore polling is not an
option
• iderw keeps the list of pending disk requests in a queue
(idequeue) and uses interrupts to signal whenever a request
has finished
• It adds b to the end of idequeue
• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues a
read or a write
• The current process is then put to sleep waiting for the operation
on b to be completed
• Once the hardware has completed the operation, it will generate
an interrupt (IRQ_IDE) which will be handled by trap by
invoking ideintr()
68. iderw
• Disk accesses take milliseconds of time therefore polling is not an
option
• iderw keeps the list of pending disk requests in a queue
(idequeue) and uses interrupts to signal whenever a request
has finished
• It adds b to the end of idequeue
• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues a
read or a write
• The current process is then put to sleep waiting for the operation
on b to be completed
• Once the hardware has completed the operation, it will generate
an interrupt (IRQ_IDE) which will be handled by trap by
invoking ideintr()
69. iderw
• Disk accesses take milliseconds of time therefore polling is not an
option
• iderw keeps the list of pending disk requests in a queue
(idequeue) and uses interrupts to signal whenever a request
has finished
• It adds b to the end of idequeue
• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues a
read or a write
• The current process is then put to sleep waiting for the operation
on b to be completed
• Once the hardware has completed the operation, it will generate
an interrupt (IRQ_IDE) which will be handled by trap by
invoking ideintr()
70. iderw
• Disk accesses take milliseconds of time therefore polling is not an
option
• iderw keeps the list of pending disk requests in a queue
(idequeue) and uses interrupts to signal whenever a request
has finished
• It adds b to the end of idequeue
• If b is the only buffer in idequeue, it instantly dispatches it to the
disk hardware by calling idestart() which either issues a
read or a write
• The current process is then put to sleep waiting for the operation
on b to be completed
• Once the hardware has completed the operation, it will generate
an interrupt (IRQ_IDE) which will be handled by trap by
invoking ideintr()
72. ideintr
1
Checks the first buffer in idequeue to find the type of the
operation (read or write)
2
If the operation was a read, it reads the data into the buffer via
insl()
3
It then sets B_VALID and clears B_DIRTY and wakes up any
processes sleeping on b
4
Finally, it dispatches the next buffer from idequeue
73. ideintr
1
Checks the first buffer in idequeue to find the type of the
operation (read or write)
2
If the operation was a read, it reads the data into the buffer via
insl()
3
It then sets B_VALID and clears B_DIRTY and wakes up any
processes sleeping on b
4
Finally, it dispatches the next buffer from idequeue
74. ideintr
1
Checks the first buffer in idequeue to find the type of the
operation (read or write)
2
If the operation was a read, it reads the data into the buffer via
insl()
3
It then sets B_VALID and clears B_DIRTY and wakes up any
processes sleeping on b
4
Finally, it dispatches the next buffer from idequeue
75. ideintr
1
Checks the first buffer in idequeue to find the type of the
operation (read or write)
2
If the operation was a read, it reads the data into the buffer via
insl()
3
It then sets B_VALID and clears B_DIRTY and wakes up any
processes sleeping on b
4
Finally, it dispatches the next buffer from idequeue
76. Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding disk
requests at a time
• They even reorder them to make efficient use of the disk arm
• Conceptually other hardware is very similar to disks
• Network buffers hold packets
• Audio device buffers hold sound samples
• Graphics card buffers hold video data
77. Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding disk
requests at a time
• They even reorder them to make efficient use of the disk arm
• Conceptually other hardware is very similar to disks
• Network buffers hold packets
• Audio device buffers hold sound samples
• Graphics card buffers hold video data
78. Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding disk
requests at a time
• They even reorder them to make efficient use of the disk arm
• Conceptually other hardware is very similar to disks
• Network buffers hold packets
• Audio device buffers hold sound samples
• Graphics card buffers hold video data
79. Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding disk
requests at a time
• They even reorder them to make efficient use of the disk arm
• Conceptually other hardware is very similar to disks
• Network buffers hold packets
• Audio device buffers hold sound samples
• Graphics card buffers hold video data
80. Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding disk
requests at a time
• They even reorder them to make efficient use of the disk arm
• Conceptually other hardware is very similar to disks
• Network buffers hold packets
• Audio device buffers hold sound samples
• Graphics card buffers hold video data
81. Modern disk controllers in a real OS
• Most disk controllers typically accept multiple outstanding disk
requests at a time
• They even reorder them to make efficient use of the disk arm
• Conceptually other hardware is very similar to disks
• Network buffers hold packets
• Audio device buffers hold sound samples
• Graphics card buffers hold video data
82. DMA
• High-bandwidth I/O devices, such as disks, graphics cards,
network cards, etc. often use direct memory access (DMA)
instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s data
field to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making the
entire process more efficient
83. DMA
• High-bandwidth I/O devices, such as disks, graphics cards,
network cards, etc. often use direct memory access (DMA)
instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s data
field to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making the
entire process more efficient
84. DMA
• High-bandwidth I/O devices, such as disks, graphics cards,
network cards, etc. often use direct memory access (DMA)
instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s data
field to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making the
entire process more efficient
85. DMA
• High-bandwidth I/O devices, such as disks, graphics cards,
network cards, etc. often use direct memory access (DMA)
instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s data
field to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making the
entire process more efficient
86. DMA
• High-bandwidth I/O devices, such as disks, graphics cards,
network cards, etc. often use direct memory access (DMA)
instead of explicit I/O (insl and outsl)
• Via DMA, controllers get direct access to physical memory
• The device driver passes the physical address of the buffer’s data
field to the device, which copies it from/to the main memory
• Once it is done, it generates an interrupt
• As a result of DMA, the CPU is not involved, hence making the
entire process more efficient
87. Dynamic interrupt routing
• In case of xv6 all disk interrupts are routed to CPU(n − 1)
• Real OSes use sophisticated algorithms to dynamically route
interrupts to processors
• The goal is to achieve optimum load balancing while maintaining
good locality
88. Dynamic interrupt routing
• In case of xv6 all disk interrupts are routed to CPU(n − 1)
• Real OSes use sophisticated algorithms to dynamically route
interrupts to processors
• The goal is to achieve optimum load balancing while maintaining
good locality
89. Dynamic interrupt routing
• In case of xv6 all disk interrupts are routed to CPU(n − 1)
• Real OSes use sophisticated algorithms to dynamically route
interrupts to processors
• The goal is to achieve optimum load balancing while maintaining
good locality
90. Reading(s)
• Chapter 3, “Traps, interrupts, and drivers”, section “Code:
Interrupts" onwards from “xv6: a simple, Unix-like teaching
operating system”