The document discusses how timers work in Linux systems. There are two kernel counters that track time - one for seconds and one for microseconds since January 1, 1970. The gettimeofday function returns the current time by reading these counters. There are also per-process timers that track the time each process has spent running. A timer interrupt triggers every 10 milliseconds to increment the jiffies counter and schedule timer bottom half processing, which updates the system clock and process times. Processes can also initialize interval timers using setitimer to generate signals when the timers expire.
Design pipeline architecture for various stage pipelinesMahmudul Hasan
This document discusses the concepts of single-cycle control, multi-cycle control, and pipelining in processors. It explains that single-cycle control has a low CPI but a long clock period, while multi-cycle control has a short clock period but high CPI. Pipelining allows overlapping the execution of instructions to improve throughput. The document presents diagrams of 5-stage instruction pipelines and describes the fetch, decode, execute, memory, and write-back stages. It also discusses pipeline hazards and performance improvements from pipelining over single-cycle and multi-cycle designs.
Video games are written as a main loop: process player input, update the state of the game, render a new frame to the screen, repeat. They do this 60 times a second, with millisecond timing. Most monitoring tools are also written as loops: send a probe, wait for the response, update a data store, sleep. Often this is done pretty slowly, maybe once a second! In video games if you can’t update fast enough, you skip the rendering step and the frame rate drops. With monitoring tools if your loop takes to long you also stop logging data as often, and instead of choppy gameplay you get gaps in your graphs, often when you need that data the most!
Let’s use ping as an example and see how we can rewrite its main loop to function more like a video game, keeping a high frame rate.
Concurrency bug identification through kernel panic log (english)Sneeker Yeh
The document outlines the analysis of a kernel panic log to identify a concurrency bug in a driver. The analysis included: 1) Log analysis found a buggy memory write, 2) Dump file analysis traced execution to this write, 3) Further log analysis found an interrupted context was involved, suggesting a concurrency bug. Tracing ARM instructions in the dump file around the interruption point helped identify that a variable was being incorrectly accessed.
This document discusses real-time operating systems (RTOS) for Cortex-M microcontrollers. It covers topics like RTOS concepts, memory management, scheduling, inter-process communication, hardware support for RTOS, and security considerations. Examples of RTOS like ARM mbed, Arduino scheduler, RTX are discussed. The document also talks about trade-offs for RTOS design involving complexity, performance and power consumption.
This document provides an overview of Contiki and its event-driven kernel, processes, protothreads, timers, and communication stack. It discusses how Contiki uses protothreads to provide sequential flow of control in an event-driven environment. It also summarizes the different types of timers in Contiki and provides an example of how to communicate using Rime, Contiki's networking stack.
Kernel Recipes 2016 - entry_*.S: A carefree stroll through kernel entry codeAnne Nicolas
I have always wondered what happens when we enter the kernel from userspace: what preparations does the hardware meet when the userspace to kernel space switch instructions are executed and back, and what does the kernel do when it executes a system call. There are also a bunch of things it does before it executes the actual syscall so I try to look at those too.
This talk is an attempt to demystify some of the aspects of the cryptic x86 entry code in arch/x86/entry/ written in assembly and how does that all fit with software-visible architecture of x86, what hardware features are being used and how.
With the hope to get more people excited about this funky piece of the kernel and maybe have the same fun we’re having.
Borislav Petkov, SUSE
Contiki os timer is an essential topic in contiki OS. This presentation describes the different types of timers and their API .
It is following the same explanation as contiki OS wiki.
The document discusses how timers work in Linux systems. There are two kernel counters that track time - one for seconds and one for microseconds since January 1, 1970. The gettimeofday function returns the current time by reading these counters. There are also per-process timers that track the time each process has spent running. A timer interrupt triggers every 10 milliseconds to increment the jiffies counter and schedule timer bottom half processing, which updates the system clock and process times. Processes can also initialize interval timers using setitimer to generate signals when the timers expire.
Design pipeline architecture for various stage pipelinesMahmudul Hasan
This document discusses the concepts of single-cycle control, multi-cycle control, and pipelining in processors. It explains that single-cycle control has a low CPI but a long clock period, while multi-cycle control has a short clock period but high CPI. Pipelining allows overlapping the execution of instructions to improve throughput. The document presents diagrams of 5-stage instruction pipelines and describes the fetch, decode, execute, memory, and write-back stages. It also discusses pipeline hazards and performance improvements from pipelining over single-cycle and multi-cycle designs.
Video games are written as a main loop: process player input, update the state of the game, render a new frame to the screen, repeat. They do this 60 times a second, with millisecond timing. Most monitoring tools are also written as loops: send a probe, wait for the response, update a data store, sleep. Often this is done pretty slowly, maybe once a second! In video games if you can’t update fast enough, you skip the rendering step and the frame rate drops. With monitoring tools if your loop takes to long you also stop logging data as often, and instead of choppy gameplay you get gaps in your graphs, often when you need that data the most!
Let’s use ping as an example and see how we can rewrite its main loop to function more like a video game, keeping a high frame rate.
Concurrency bug identification through kernel panic log (english)Sneeker Yeh
The document outlines the analysis of a kernel panic log to identify a concurrency bug in a driver. The analysis included: 1) Log analysis found a buggy memory write, 2) Dump file analysis traced execution to this write, 3) Further log analysis found an interrupted context was involved, suggesting a concurrency bug. Tracing ARM instructions in the dump file around the interruption point helped identify that a variable was being incorrectly accessed.
This document discusses real-time operating systems (RTOS) for Cortex-M microcontrollers. It covers topics like RTOS concepts, memory management, scheduling, inter-process communication, hardware support for RTOS, and security considerations. Examples of RTOS like ARM mbed, Arduino scheduler, RTX are discussed. The document also talks about trade-offs for RTOS design involving complexity, performance and power consumption.
This document provides an overview of Contiki and its event-driven kernel, processes, protothreads, timers, and communication stack. It discusses how Contiki uses protothreads to provide sequential flow of control in an event-driven environment. It also summarizes the different types of timers in Contiki and provides an example of how to communicate using Rime, Contiki's networking stack.
Kernel Recipes 2016 - entry_*.S: A carefree stroll through kernel entry codeAnne Nicolas
I have always wondered what happens when we enter the kernel from userspace: what preparations does the hardware meet when the userspace to kernel space switch instructions are executed and back, and what does the kernel do when it executes a system call. There are also a bunch of things it does before it executes the actual syscall so I try to look at those too.
This talk is an attempt to demystify some of the aspects of the cryptic x86 entry code in arch/x86/entry/ written in assembly and how does that all fit with software-visible architecture of x86, what hardware features are being used and how.
With the hope to get more people excited about this funky piece of the kernel and maybe have the same fun we’re having.
Borislav Petkov, SUSE
Contiki os timer is an essential topic in contiki OS. This presentation describes the different types of timers and their API .
It is following the same explanation as contiki OS wiki.
UM2019 Extended BPF: A New Type of SoftwareBrendan Gregg
BPF (Berkeley Packet Filter) has evolved from a limited virtual machine for efficient packet filtering to a new type of software called extended BPF. Extended BPF allows for custom, efficient, and production-safe performance analysis tools and observability programs to be run in the Linux kernel through BPF. It enables new event-based applications running as BPF programs attached to various kernel events like kprobes, uprobes, tracepoints, sockets, and more. Major companies like Facebook, Google, and Netflix are using BPF programs for tasks like intrusion detection, container security, firewalling, and observability with over 150,000 AWS instances running BPF programs. BPF provides a new program model and security features compared
Using the new extended Berkley Packet Filter capabilities in Linux to the improve performance of auditing security relevant kernel events around network, file and process actions.
This document is the manual for D-ITG V. 2.6.1d, which is a network performance measurement tool developed by researchers at the University of Naples Federico II. It describes the usage and options of various programs that are part of the D-ITG platform, including ITGSend for generating network traffic, ITGRecv for receiving traffic, and ITGLog, ITGDec, and ITGplot for analyzing results. The manual provides examples of how to use each program to perform different types of network measurements and traffic generation.
Core Scheduling for Virtualization: Where are We? (If we Want it!)Dario Faggioli
Clever scheduling of virtual CPUs on Symmetric MultiThreaded systems for, among other things, making highly impractical side-channel attacks even more unpractical, is no new idea. Unfortunately, via exploiting L1TF and MDS vulnerabilities in Intel CPUs, impractical is becoming practical!
But, instead than disabling SMT, we can avoid that VM share cores. This is called core-scheduling, and implementing it requires quite some scheduler changes. Nevertheless, work toward that is being done for both KVM and Xen (and other hypervisors have it already).
After an overview of L1TF and MDS, we will see how core-scheduling may help and why it is so tricky to implement (although in different ways) for both KVM and Xen.
We will show numbers from performance evaluation of the currently available implementations. In fact, all this only matters if performance are better than turning SMT off.
Kernel Recipes 2017 - Modern Key Management with GPG - Werner KochAnne Nicolas
Although GnuPG 2 has been around for nearly 15 years, the old 1.4 version was still in wide use. With Debian and others making 2.1 the default, many interesting things can now be done. In this talk he will explain the advantages of modern key algorithms, like ed25519, and why gpg relaxed some of its more paranoid defaults. The new –quick commands of gpg for easily scriptable key management will be described as well as the new key discovery methods. Finally hints for integration of gpg into other programs will be given.
Werner Koch, g10code
SFO15-202: Towards Multi-Threaded Tiny Code Generator (TCG) in QEMULinaro
This document discusses moving QEMU's Tiny Code Generator (TCG) to a multi-threaded model to take advantage of multi-core systems. It describes the current single-threaded TCG process model and global state. Approaches considered for multi-threading include using threads/locks, processes/IPC, or rewriting TCG from scratch. Key challenges addressed are protecting code generation globals and implementing atomic memory operations and memory barriers in a multi-threaded context. Patches have been contributed to address these issues and enable multi-threaded TCG. Further work remains to fully enable it across all QEMU backends and architectures.
Memory is organized in a hierarchy from fast but small CPU caches to larger but slower dynamic RAM (DRAM) and static RAM (SRAM), with the Linux kernel using zone allocation, buddy allocation, and slab allocation to manage physical memory and handle fragmentation issues across these storage and processing layers. Applications rely on standard library allocators like malloc while the kernel uses slab allocators like SLAB, SLUB, and SLOB to manage memory for internal data structures.
This document summarizes discussions from the Linaro Connect Q4-11 Power Management Working Group about scheduling domains and load balancing on multicore ARM processors. It describes using sched_mc domains to balance load at the multicore level instead of the CPU level. It also discusses using CPU power scaling to emulate different topologies, like packing tasks onto fewer cores at low load to save power on quad-core CPUs or pulling tasks to a single core on a dual-core system. Open issues around idle load balancing and spurious wakeups with these approaches are also outlined. Future work on load balancing for asymmetric big.LITTLE systems is mentioned.
Translation Cache Policies for Dynamic Binary TranslationSaber Ferjani
Our project comes in order to enhance Qemu simulation speed, through the proposal of a new cache algorithm that detect frequently used blocks and improves their reuse ratio.
-> Deep dive inside the kernel Interrupt management subsystem.
-> Entire presentation is oriented towards 8259 Interrupt controller.
-> Detail understanding of how request_irq() function works.
Spying on the Linux kernel for fun and profitAndrea Righi
Do you ever wonder what the kernel is doing while your code is running? This talk will explore some methodologies and techniques (eBPF, ftrace, etc.) to look under the hood of the Linux kernel and understand what it’s actually doing behind the scenes.
F9 microkernel code reading part 4 memory managementBenux Wei
This document provides an overview of memory management in the F9 microkernel, including:
- A brief overview of the ARM memory system and memory types.
- Details of F9's memory management including bit-banding, unaligned transfers, and exclusive accessing.
- The Memory Protection Unit (MPU) which defines memory access permissions and can generate faults for prohibited accesses.
- An agenda for reading and understanding the F9 memory management source code.
Linux 4.x Tracing: Performance Analysis with bcc/BPFBrendan Gregg
Talk about bcc/eBPF for SCALE15x (2017) by Brendan Gregg. "BPF (Berkeley Packet Filter) has been enhanced in the Linux 4.x series and now powers a large collection of performance analysis and observability tools ready for you to use, included in the bcc (BPF Complier Collection) open source project. BPF nowadays can do system tracing, software defined networks, and kernel fast path: much more than just filtering packets! This talk will focus on the bcc/BPF tools for performance analysis, which make use of other built in Linux capabilities: dynamic tracing (kprobes and uprobes) and static tracing (tracepoints and USDT). There are now bcc tools for 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. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. Tracing superpowers have finally arrived, built in to Linux."
F9 Microkernel code reading part 2 schedulingBenux Wei
F9 is an experimental microkernel used to construct flexible embedded systems. It implements a tickless scheduler to improve energy efficiency by avoiding periodic timer interrupts. The scheduler code uses scheduling slots and a thread control block to select the next runnable thread. Important files related to scheduling include sched.c, ktimer.c, and thread.c. The kernel aims to support real-time and time-sharing applications on ARM Cortex-M microprocessors.
This document provides an overview of QEMU, including its use of dynamic translation and Tiny Code Generator (TCG) to emulate target CPUs on the host system. It discusses how QEMU translates target instructions into a RISC-like intermediate representation (TCG ops), optimizes and converts them to host instructions. The document also mentions Linaro's work with QEMU and a QEMU monitor tool for debugging ARM systems emulated by QEMU.
The document discusses kernel debugging techniques. It covers analyzing kernel error logs, debugging memory errors, detecting kernel deadlocks, and troubleshooting login issues. The key debugging techniques mentioned are using kernel log functions to output error information, understanding the structure of kernel bug logs, tracing from assembly to C code, and using tools like AddressSanitizer to detect memory errors.
Kernel Recipes 2015: Introduction to Kernel Power ManagementAnne Nicolas
The document introduces kernel power management concepts in Linux, including static and dynamic power management, idle power management for CPUs and devices, and the evolving driver model. It covers key frameworks like CPU frequency scaling, regulators, runtime power management, and power domains. Documentation files are referenced throughout for further reading.
bcc/BPF tools - Strategy, current tools, future challengesIO Visor Project
Brendan Gregg discusses the current state and future potential of BPF and BCC tools for observability in Linux. He outlines 18 areas where BPF support has progressed and 16 areas still needing work. Gregg also discusses challenges like dynamic tracing stability, overhead, ease of coding, and developing visualizations. He proposes finishing ports of his old DTrace tools and links to resources on BPF, BCC, and flame graphs.
Timers in Linux use jiffies which increment every clock interrupt to provide a timestamp. The HZ value determines the frequency of clock interrupts, with typical values being 1000 Hz or 100 Hz. High resolution timers allow nanosecond precision and are implemented as a red-black tree. They can be used for timers that need high resolution and are expected to expire. Tickless kernels remove the need for idle CPUs to process timer interrupts every jiffy, saving power.
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.
UM2019 Extended BPF: A New Type of SoftwareBrendan Gregg
BPF (Berkeley Packet Filter) has evolved from a limited virtual machine for efficient packet filtering to a new type of software called extended BPF. Extended BPF allows for custom, efficient, and production-safe performance analysis tools and observability programs to be run in the Linux kernel through BPF. It enables new event-based applications running as BPF programs attached to various kernel events like kprobes, uprobes, tracepoints, sockets, and more. Major companies like Facebook, Google, and Netflix are using BPF programs for tasks like intrusion detection, container security, firewalling, and observability with over 150,000 AWS instances running BPF programs. BPF provides a new program model and security features compared
Using the new extended Berkley Packet Filter capabilities in Linux to the improve performance of auditing security relevant kernel events around network, file and process actions.
This document is the manual for D-ITG V. 2.6.1d, which is a network performance measurement tool developed by researchers at the University of Naples Federico II. It describes the usage and options of various programs that are part of the D-ITG platform, including ITGSend for generating network traffic, ITGRecv for receiving traffic, and ITGLog, ITGDec, and ITGplot for analyzing results. The manual provides examples of how to use each program to perform different types of network measurements and traffic generation.
Core Scheduling for Virtualization: Where are We? (If we Want it!)Dario Faggioli
Clever scheduling of virtual CPUs on Symmetric MultiThreaded systems for, among other things, making highly impractical side-channel attacks even more unpractical, is no new idea. Unfortunately, via exploiting L1TF and MDS vulnerabilities in Intel CPUs, impractical is becoming practical!
But, instead than disabling SMT, we can avoid that VM share cores. This is called core-scheduling, and implementing it requires quite some scheduler changes. Nevertheless, work toward that is being done for both KVM and Xen (and other hypervisors have it already).
After an overview of L1TF and MDS, we will see how core-scheduling may help and why it is so tricky to implement (although in different ways) for both KVM and Xen.
We will show numbers from performance evaluation of the currently available implementations. In fact, all this only matters if performance are better than turning SMT off.
Kernel Recipes 2017 - Modern Key Management with GPG - Werner KochAnne Nicolas
Although GnuPG 2 has been around for nearly 15 years, the old 1.4 version was still in wide use. With Debian and others making 2.1 the default, many interesting things can now be done. In this talk he will explain the advantages of modern key algorithms, like ed25519, and why gpg relaxed some of its more paranoid defaults. The new –quick commands of gpg for easily scriptable key management will be described as well as the new key discovery methods. Finally hints for integration of gpg into other programs will be given.
Werner Koch, g10code
SFO15-202: Towards Multi-Threaded Tiny Code Generator (TCG) in QEMULinaro
This document discusses moving QEMU's Tiny Code Generator (TCG) to a multi-threaded model to take advantage of multi-core systems. It describes the current single-threaded TCG process model and global state. Approaches considered for multi-threading include using threads/locks, processes/IPC, or rewriting TCG from scratch. Key challenges addressed are protecting code generation globals and implementing atomic memory operations and memory barriers in a multi-threaded context. Patches have been contributed to address these issues and enable multi-threaded TCG. Further work remains to fully enable it across all QEMU backends and architectures.
Memory is organized in a hierarchy from fast but small CPU caches to larger but slower dynamic RAM (DRAM) and static RAM (SRAM), with the Linux kernel using zone allocation, buddy allocation, and slab allocation to manage physical memory and handle fragmentation issues across these storage and processing layers. Applications rely on standard library allocators like malloc while the kernel uses slab allocators like SLAB, SLUB, and SLOB to manage memory for internal data structures.
This document summarizes discussions from the Linaro Connect Q4-11 Power Management Working Group about scheduling domains and load balancing on multicore ARM processors. It describes using sched_mc domains to balance load at the multicore level instead of the CPU level. It also discusses using CPU power scaling to emulate different topologies, like packing tasks onto fewer cores at low load to save power on quad-core CPUs or pulling tasks to a single core on a dual-core system. Open issues around idle load balancing and spurious wakeups with these approaches are also outlined. Future work on load balancing for asymmetric big.LITTLE systems is mentioned.
Translation Cache Policies for Dynamic Binary TranslationSaber Ferjani
Our project comes in order to enhance Qemu simulation speed, through the proposal of a new cache algorithm that detect frequently used blocks and improves their reuse ratio.
-> Deep dive inside the kernel Interrupt management subsystem.
-> Entire presentation is oriented towards 8259 Interrupt controller.
-> Detail understanding of how request_irq() function works.
Spying on the Linux kernel for fun and profitAndrea Righi
Do you ever wonder what the kernel is doing while your code is running? This talk will explore some methodologies and techniques (eBPF, ftrace, etc.) to look under the hood of the Linux kernel and understand what it’s actually doing behind the scenes.
F9 microkernel code reading part 4 memory managementBenux Wei
This document provides an overview of memory management in the F9 microkernel, including:
- A brief overview of the ARM memory system and memory types.
- Details of F9's memory management including bit-banding, unaligned transfers, and exclusive accessing.
- The Memory Protection Unit (MPU) which defines memory access permissions and can generate faults for prohibited accesses.
- An agenda for reading and understanding the F9 memory management source code.
Linux 4.x Tracing: Performance Analysis with bcc/BPFBrendan Gregg
Talk about bcc/eBPF for SCALE15x (2017) by Brendan Gregg. "BPF (Berkeley Packet Filter) has been enhanced in the Linux 4.x series and now powers a large collection of performance analysis and observability tools ready for you to use, included in the bcc (BPF Complier Collection) open source project. BPF nowadays can do system tracing, software defined networks, and kernel fast path: much more than just filtering packets! This talk will focus on the bcc/BPF tools for performance analysis, which make use of other built in Linux capabilities: dynamic tracing (kprobes and uprobes) and static tracing (tracepoints and USDT). There are now bcc tools for 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. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. Tracing superpowers have finally arrived, built in to Linux."
F9 Microkernel code reading part 2 schedulingBenux Wei
F9 is an experimental microkernel used to construct flexible embedded systems. It implements a tickless scheduler to improve energy efficiency by avoiding periodic timer interrupts. The scheduler code uses scheduling slots and a thread control block to select the next runnable thread. Important files related to scheduling include sched.c, ktimer.c, and thread.c. The kernel aims to support real-time and time-sharing applications on ARM Cortex-M microprocessors.
This document provides an overview of QEMU, including its use of dynamic translation and Tiny Code Generator (TCG) to emulate target CPUs on the host system. It discusses how QEMU translates target instructions into a RISC-like intermediate representation (TCG ops), optimizes and converts them to host instructions. The document also mentions Linaro's work with QEMU and a QEMU monitor tool for debugging ARM systems emulated by QEMU.
The document discusses kernel debugging techniques. It covers analyzing kernel error logs, debugging memory errors, detecting kernel deadlocks, and troubleshooting login issues. The key debugging techniques mentioned are using kernel log functions to output error information, understanding the structure of kernel bug logs, tracing from assembly to C code, and using tools like AddressSanitizer to detect memory errors.
Kernel Recipes 2015: Introduction to Kernel Power ManagementAnne Nicolas
The document introduces kernel power management concepts in Linux, including static and dynamic power management, idle power management for CPUs and devices, and the evolving driver model. It covers key frameworks like CPU frequency scaling, regulators, runtime power management, and power domains. Documentation files are referenced throughout for further reading.
bcc/BPF tools - Strategy, current tools, future challengesIO Visor Project
Brendan Gregg discusses the current state and future potential of BPF and BCC tools for observability in Linux. He outlines 18 areas where BPF support has progressed and 16 areas still needing work. Gregg also discusses challenges like dynamic tracing stability, overhead, ease of coding, and developing visualizations. He proposes finishing ports of his old DTrace tools and links to resources on BPF, BCC, and flame graphs.
Timers in Linux use jiffies which increment every clock interrupt to provide a timestamp. The HZ value determines the frequency of clock interrupts, with typical values being 1000 Hz or 100 Hz. High resolution timers allow nanosecond precision and are implemented as a red-black tree. They can be used for timers that need high resolution and are expected to expire. Tickless kernels remove the need for idle CPUs to process timer interrupts every jiffy, saving power.
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.
RTOS Material hfffffffffffffffffffffffffffffffffffffadugnanegero
This document provides an overview of real-time operating systems and kernel concepts across 34 slides. The key topics covered include real-time kernels, tasks and processes, scheduling algorithms like priority-based and cyclic executives, intertask communication methods like mailboxes and semaphores, and synchronization techniques.
The document discusses prerequisites, log messages, and constraints for Synopsys IC Compiler clock tree synthesis (CTS). It describes running check_clock_tree and check_legality commands as prerequisites. It explains how to enable debug messages and view messages in the compile_clock_tree log related to buffer characterization, CTS stages, constraints, and results. Threshold warnings for tight constraints on maximum capacitance and transition times are also discussed.
This document provides an overview of clock synchronization in distributed systems. It discusses how physical clocks can differ slightly in frequency and how precise atomic clocks are used to define International Atomic Time (TAI) and Universal Coordinated Time (UTC). It also describes several common clock synchronization algorithms, including Cristian's algorithm, the Berkeley algorithm, and averaging algorithms. Logical clocks are introduced as an alternative to synchronized physical clocks for maintaining consistency in distributed algorithms. Lamport timestamps are presented as a way to totally order events in a distributed system.
The document discusses real-time operating systems for embedded systems. It describes that RTOS are necessary for systems with scheduling of multiple processes and devices. An RTOS kernel manages tasks, inter-task communication, memory allocation, timers and I/O devices. The document provides examples of creating tasks to blink an LED and print to USART ports, using a semaphore for synchronization between tasks. The tasks are run and output is seen on a Minicom terminal.
This document discusses making Linux capable of hard real-time performance. It begins by defining hard and soft real-time systems and explaining that real-time does not necessarily mean fast but rather determinism. It then covers general concepts around real-time performance in Linux like preemption, interrupts, context switching, and scheduling. Specific features in Linux like RT-Preempt, priority inheritance, and threaded interrupts that improve real-time capabilities are also summarized.
Getting date and time from ntp server with esp8266 node mcuElaf A.Saeed
Getting Date & Time From NTP Server With ESP8266 NodeMCU
-----------------------------------------------------------------------------------
Email: elafe1888@gmail.com
linkden: www.linkedin.com/in/elaf-a-saeed-97bbb6150
facebook: https://www.facebook.com/profile.php?id=100004305557442
twitter: https://twitter.com/ElafASaeed1
github: https://github.com/ElafAhmedSaeed
youtube: https://youtube.com/channel/UCE_RiXkyqREUdLAiZcbBqSg
slideshare: https://www.slideshare.net/ElafASaeed
Slideplayer: https://slideplayer.com/search/?q=Elaf+A.Saeed
Google Scholar: https://scholar.google.com/citations?user=VIpVZKkAAAAJ&hl=ar&gmla=AJsN-F7PIgAjWJ44Hzb18fwPqJaaUmG0XzbLdzx09
IJCER (www.ijceronline.com) International Journal of computational Engineeri...ijceronline
The document proposes implementing register files in the processor hardware to improve context switching performance in hard real-time systems. Conventionally, context switching involves saving processor registers to external memory, which takes 50-80 clock cycles. The proposed approach saves contexts to register files within the processor, requiring only 4 clock cycles. Software and a small operating system were modified to use new "save context" and "restore context" instructions. Simulation results showed contexts being saved and restored from an internal register file in 2 clock cycles each. Two test applications demonstrated the performance improvement from using internal register files versus external memory for context switching.
Network & Filesystem: Doing less cross rings memory copyScaleway
The document discusses optimization techniques in the Linux kernel to reduce memory copying costs, specifically zero-copy approaches. It provides:
1. A brief history of context switches in systems and the costs associated with copying data between kernel and user space during system calls.
2. An overview of common Linux system calls like read() and write() that involve data copies between kernel and user spaces.
3. Details on zero-copy Linux kernel APIs like splice() and sendfile() that can move data between file descriptors without copying to/from kernel space, improving performance.
4. Benchmark results showing a zero-copy file upload approach achieving over 3Gbps compared to 940Mbps for a normal copy-based
The document discusses parallel logic concepts from hardware design and how they can be applied to event-driven firmware development. It describes how VHDL uses process blocks with sensitivity lists to simulate parallel hardware logic. This allows describing sections of sequential logic that run concurrently. The document explains how similar concepts of process blocks and sensitivity lists can be implemented in firmware to achieve low-cost multitasking. It also discusses how ARM Cortex-M processors support efficient bit-banding memory remapping that is useful for inter-process communication.
This document discusses time measurement in embedded systems. It explains that most embedded applications need to measure time for functions like auto power off, playing media, and measuring elapsed time. It also discusses real-time systems and the difference between hard and soft real-time constraints. Examples of needing real-time measurement include missile control and autonomous vehicles. The document then talks about different ways to measure time on embedded platforms like Arduino and ESP32 using millis(), micros(), and interrupts. It provides examples of using delays or interrupts to trigger a task repeatedly every second. Finally, it provides homework questions involving measuring elapsed time and triggering tasks using delays or interrupts on Arduino or C/C++.
1) The document discusses real-time operating systems (RTOS) and their use in embedded systems. An RTOS is an operating system that is designed to serve applications that require deterministic execution behavior and response times.
2) An RTOS kernel contains minimal services for tasks like scheduling, synchronization, and interrupt handling. It implements policies for prioritizing time-critical tasks.
3) Tasks in an RTOS can transition between different states like ready, running, blocked as they execute and wait for resources. An RTOS uses techniques like fixed-size memory blocks and preemptive multithreading to provide predictable timing.
Accurate Synchronization of EtherCAT Systems Using Distributed ClocksDesign World
Synchronization and determinism are important considerations when selecting an industrial control system and the associated fieldbus. Additionally, it’s important for field devices to have network-wide interrupts for activating outputs, capturing input data, oversampling or latching events. These are all significant facets in the overall network synchronization scheme.
This webinar on Tuesday, Oct. 23 at 2 PM EST will explain how the Distributed Clock mechanism in EtherCAT works to meet all of these functions using properties inherent to the protocol. This can be done using a standard Ethernet network adaptor, all without the overhead of IEEE 1588.
Attend this webinar to learn:
How Distributed Clocks (DCs) in EtherCAT facilitate measurement of propagation delay throughout the system and synchronize network devices to a single time value
What EtherCAT slave devices can do to facilitate temporal behavior for outputs and inputs as well as implementing data oversampling
More about some of the concepts that enable EtherCAT to have a high scan rate as well as high levels of synchronization
The document describes the process of implementing SMP support for OpenBSD on a SGI Octane 2 machine. Key steps included restructuring per-processor data, implementing locking primitives, handling hardware aspects like spinning up secondary processors, and debugging challenges like detecting deadlocks. Debugging was made difficult by timing issues but was aided by tools like JTAG, DDB, printfs, and modifying locks to record stuck locations. Interrupts could block inter-processor communication so the clock handler was modified to re-enable interrupts during locking.
Clock tree synthesis log messages provide information about:
1) Preprocessing steps like design updates, buffer characterization, and clock tree constraints.
2) The clock tree synthesis process which includes clustering, meeting timing targets, and reporting results.
3) Post processing steps like embedded clock tree optimization, DRC fixing, and placement legalization.
Optimizing Gradle Builds - Gradle DPE Tour Berlin 2024Sinan KOZAK
Sinan from the Delivery Hero mobile infrastructure engineering team shares a deep dive into performance acceleration with Gradle build cache optimizations. Sinan shares their journey into solving complex build-cache problems that affect Gradle builds. By understanding the challenges and solutions found in our journey, we aim to demonstrate the possibilities for faster builds. The case study reveals how overlapping outputs and cache misconfigurations led to significant increases in build times, especially as the project scaled up with numerous modules using Paparazzi tests. The journey from diagnosing to defeating cache issues offers invaluable lessons on maintaining cache integrity without sacrificing functionality.
Embedded machine learning-based road conditions and driving behavior monitoringIJECEIAES
Car accident rates have increased in recent years, resulting in losses in human lives, properties, and other financial costs. An embedded machine learning-based system is developed to address this critical issue. The system can monitor road conditions, detect driving patterns, and identify aggressive driving behaviors. The system is based on neural networks trained on a comprehensive dataset of driving events, driving styles, and road conditions. The system effectively detects potential risks and helps mitigate the frequency and impact of accidents. The primary goal is to ensure the safety of drivers and vehicles. Collecting data involved gathering information on three key road events: normal street and normal drive, speed bumps, circular yellow speed bumps, and three aggressive driving actions: sudden start, sudden stop, and sudden entry. The gathered data is processed and analyzed using a machine learning system designed for limited power and memory devices. The developed system resulted in 91.9% accuracy, 93.6% precision, and 92% recall. The achieved inference time on an Arduino Nano 33 BLE Sense with a 32-bit CPU running at 64 MHz is 34 ms and requires 2.6 kB peak RAM and 139.9 kB program flash memory, making it suitable for resource-constrained embedded systems.
A SYSTEMATIC RISK ASSESSMENT APPROACH FOR SECURING THE SMART IRRIGATION SYSTEMSIJNSA Journal
The smart irrigation system represents an innovative approach to optimize water usage in agricultural and landscaping practices. The integration of cutting-edge technologies, including sensors, actuators, and data analysis, empowers this system to provide accurate monitoring and control of irrigation processes by leveraging real-time environmental conditions. The main objective of a smart irrigation system is to optimize water efficiency, minimize expenses, and foster the adoption of sustainable water management methods. This paper conducts a systematic risk assessment by exploring the key components/assets and their functionalities in the smart irrigation system. The crucial role of sensors in gathering data on soil moisture, weather patterns, and plant well-being is emphasized in this system. These sensors enable intelligent decision-making in irrigation scheduling and water distribution, leading to enhanced water efficiency and sustainable water management practices. Actuators enable automated control of irrigation devices, ensuring precise and targeted water delivery to plants. Additionally, the paper addresses the potential threat and vulnerabilities associated with smart irrigation systems. It discusses limitations of the system, such as power constraints and computational capabilities, and calculates the potential security risks. The paper suggests possible risk treatment methods for effective secure system operation. In conclusion, the paper emphasizes the significant benefits of implementing smart irrigation systems, including improved water conservation, increased crop yield, and reduced environmental impact. Additionally, based on the security analysis conducted, the paper recommends the implementation of countermeasures and security approaches to address vulnerabilities and ensure the integrity and reliability of the system. By incorporating these measures, smart irrigation technology can revolutionize water management practices in agriculture, promoting sustainability, resource efficiency, and safeguarding against potential security threats.
Redefining brain tumor segmentation: a cutting-edge convolutional neural netw...IJECEIAES
Medical image analysis has witnessed significant advancements with deep learning techniques. In the domain of brain tumor segmentation, the ability to
precisely delineate tumor boundaries from magnetic resonance imaging (MRI)
scans holds profound implications for diagnosis. This study presents an ensemble convolutional neural network (CNN) with transfer learning, integrating
the state-of-the-art Deeplabv3+ architecture with the ResNet18 backbone. The
model is rigorously trained and evaluated, exhibiting remarkable performance
metrics, including an impressive global accuracy of 99.286%, a high-class accuracy of 82.191%, a mean intersection over union (IoU) of 79.900%, a weighted
IoU of 98.620%, and a Boundary F1 (BF) score of 83.303%. Notably, a detailed comparative analysis with existing methods showcases the superiority of
our proposed model. These findings underscore the model’s competence in precise brain tumor localization, underscoring its potential to revolutionize medical
image analysis and enhance healthcare outcomes. This research paves the way
for future exploration and optimization of advanced CNN models in medical
imaging, emphasizing addressing false positives and resource efficiency.
Advanced control scheme of doubly fed induction generator for wind turbine us...IJECEIAES
This paper describes a speed control device for generating electrical energy on an electricity network based on the doubly fed induction generator (DFIG) used for wind power conversion systems. At first, a double-fed induction generator model was constructed. A control law is formulated to govern the flow of energy between the stator of a DFIG and the energy network using three types of controllers: proportional integral (PI), sliding mode controller (SMC) and second order sliding mode controller (SOSMC). Their different results in terms of power reference tracking, reaction to unexpected speed fluctuations, sensitivity to perturbations, and resilience against machine parameter alterations are compared. MATLAB/Simulink was used to conduct the simulations for the preceding study. Multiple simulations have shown very satisfying results, and the investigations demonstrate the efficacy and power-enhancing capabilities of the suggested control system.
Literature Review Basics and Understanding Reference Management.pptxDr Ramhari Poudyal
Three-day training on academic research focuses on analytical tools at United Technical College, supported by the University Grant Commission, Nepal. 24-26 May 2024
CHINA’S GEO-ECONOMIC OUTREACH IN CENTRAL ASIAN COUNTRIES AND FUTURE PROSPECTjpsjournal1
The rivalry between prominent international actors for dominance over Central Asia's hydrocarbon
reserves and the ancient silk trade route, along with China's diplomatic endeavours in the area, has been
referred to as the "New Great Game." This research centres on the power struggle, considering
geopolitical, geostrategic, and geoeconomic variables. Topics including trade, political hegemony, oil
politics, and conventional and nontraditional security are all explored and explained by the researcher.
Using Mackinder's Heartland, Spykman Rimland, and Hegemonic Stability theories, examines China's role
in Central Asia. This study adheres to the empirical epistemological method and has taken care of
objectivity. This study analyze primary and secondary research documents critically to elaborate role of
china’s geo economic outreach in central Asian countries and its future prospect. China is thriving in trade,
pipeline politics, and winning states, according to this study, thanks to important instruments like the
Shanghai Cooperation Organisation and the Belt and Road Economic Initiative. According to this study,
China is seeing significant success in commerce, pipeline politics, and gaining influence on other
governments. This success may be attributed to the effective utilisation of key tools such as the Shanghai
Cooperation Organisation and the Belt and Road Economic Initiative.
Harnessing WebAssembly for Real-time Stateless Streaming PipelinesChristina Lin
Traditionally, dealing with real-time data pipelines has involved significant overhead, even for straightforward tasks like data transformation or masking. However, in this talk, we’ll venture into the dynamic realm of WebAssembly (WASM) and discover how it can revolutionize the creation of stateless streaming pipelines within a Kafka (Redpanda) broker. These pipelines are adept at managing low-latency, high-data-volume scenarios.
Understanding Inductive Bias in Machine LearningSUTEJAS
This presentation explores the concept of inductive bias in machine learning. It explains how algorithms come with built-in assumptions and preferences that guide the learning process. You'll learn about the different types of inductive bias and how they can impact the performance and generalizability of machine learning models.
The presentation also covers the positive and negative aspects of inductive bias, along with strategies for mitigating potential drawbacks. We'll explore examples of how bias manifests in algorithms like neural networks and decision trees.
By understanding inductive bias, you can gain valuable insights into how machine learning models work and make informed decisions when building and deploying them.
KuberTENes Birthday Bash Guadalajara - K8sGPT first impressionsVictor Morales
K8sGPT is a tool that analyzes and diagnoses Kubernetes clusters. This presentation was used to share the requirements and dependencies to deploy K8sGPT in a local environment.
3. 1
KERNAL NOTION OF TIME
The kernel knows the preprogrammed tick rate, so it knows the time between any
two successive timer interrupts. This period is called a tick and is equal to 1/(tick
rate) seconds.
This is how the kernel keeps track of both wall time and system uptime.
Wall time—the actual time of day—is important to user-space applications.
The system uptime—the relative time since the system booted—is useful to both
kernel-space and user-space.
4. 1
KERNAL NOTION OF TIME
Some Functions Of Timer Interrupt
Updating the system uptime.
Updating the time of day.
On an SMP system, ensuring that the
scheduler runqueues are balanced and, if
not, balancing them.
Running any dynamic timers that have
expired.
The Tick Rate: HZ
The frequency of the system timer (the tick
rate) is programmed on system boot based
on a static preprocessor define, HZ.The value
of HZ differs for each supported architecture.
The tick rate has a frequency of HZ hertz and
a period of 1/HZ seconds. For example, by
default the x86 architecture defines HZ to be
100.
The frequency of the timer interrupt is
important. So changing its frequency has a
reasonable impact on the system.
5. 1
KERNAL NOTION OF TIME
Advantages with a Larger HZ
Kernel timers execute with finer
resolution and increased accuracy.
Measurements, such as resource
usage or the system uptime, are
recorded with a finer resolution.
Process preemption occurs more
accurately.
Disadvantages with a Larger HZ
A higher tick rate implies more frequent timer
interrupts, which implies higher overhead.
The higher the tick rate,the more time the
processor spends executing the timer
interrupt.
More frequent thrashing of the processor’s
cache and increase in power consumption.
6. 1
KERNAL NOTION OF TIME
A Tickless OS
The Linux kernel supports an option known as a tickless operation. When a
kernel is built with the CONFIG_HZ configuration option set, the system
dynamically schedules the timer interrupt in accordance with pending timers.
Instead of firing the timer interrupt every, say, 1ms, the interrupt is dynamically
scheduled and rescheduled as needed.
With a tickless system, moments of idleness are not interrupted by
unnecessary time interrupts, reducing system power consumption also
reduction in overhead.
7. 1
JIFFIES
2
The Etymology of
the Jiffy:
The origin of the term jiffy is
unknown. Phrases such as in a
jiffy are thought to originate from
18th-century England. In lay
terms, jiffy refers to an
indeterminate but brief period of
time.
In computer engineering, a jiffy
is often the time between two
successive clock cycles. In
electrical engineering, a jiffy is
the time to complete one AC
(alternating current) cycle.
1
The global variable jiffies holds the number of ticks that have occurred since the
system
booted. On boot, the kernel initializes the variable to zero, and it is incremented by
one during each timer interrupt.
There are HZ timer interrupts in a second,
There are HZ jiffies in a second.
The system uptime is therefore jiffies/HZ seconds.
The jiffies variable is declared in <linux/jiffies.h> as
extern unsigned long volatile jiffies;
The following expression converts from seconds to a unit of jiffies:
(seconds * HZ)
Likewise, this expression converts from jiffies to seconds:
(jiffies / HZ)
For example, code often needs to set a value for some time in the future, for example:
unsigned long time_stamp = jiffies;
unsigned long next_tick = jiffies + 1;
unsigned long later = jiffies + 5*HZ;
unsigned long fraction = jiffies + HZ / 10;
8. 1
JIFFIES
2
The jiffies variable has always been an unsigned long,
32 bits in size on 32-bit architectures and
64-bits on 64-bit architectures.
With a tick rate of 100, a 32-bit jiffies variable would overflow in about 497 days. With HZ
increased to 1000, however, that overflow now occurs in just 49.7 days!
If jiffies were stored in a 64-bit variable on all architectures, then for any reasonable HZ value the
jiffies variable would never overflow in anyone’s lifetime
Internal Representation of Jiffies
A second variable is also defined in : extern u64 jiffies_64;
Code that accesses jiffies simply reads the lower
32 bits of jiffies_64.
The function get_jiffies_64() can be used to read
the full 64-bit value.
9. 1
JIFFIES
2
Look at an example of a wraparound:
unsigned long timeout = jiffies + HZ/2; /*
timeout in 0.5s */
/* do some work ... */
/* then see whether we took too long */
if (timeout > jiffies) { /* we did not time out,
good ... */ }
else { /* we timed out, error ... */ }
Jiffies Wraparound
Thankfully, the kernel provides four macros
for comparing tick counts that correctly
handle wraparound in the tick count. They
are in . Listed here are simplified versions of
the macros:
define time_after(unknown, known)
((long)(known) - (long)(unknown) < 0)
#define time_before(unknown, known)
((long)(unknown) - (long)(known) < 0)
#define time_after_eq(unknown, known)
((long)(unknown) - (long)(known) >= 0)
#define time_before_eq(unknown, known)
((long)(known) - (long)(unknown) >= 0)
10. 1
JIFFIES
2
How It Actually Work
time_after(a,b) returns true if the time a is
after time b.
A special function is needed because 32-bit
architectures cannot atomically access both 32-bit
words in a 64-bit value.
The special function locks the jiffies count
via the xtime_lock lock before reading
Suppose b is 253, and five ticks later jiffies
has wrapped around to 2. We would therefore
expect
time_after(2,253) to return true. And it does
(using int8_t to denote a signed 8-bit value):
(int8_t) 253 - (int8_t) 2 == -3 - 2 == -5 < 0
You can try other values, too. This one is
trickier, for time_after(128, 127), which should be
true as well:
(int8_t) 127 - (int8_t) 128 == 127 - (-128) ==
255 == -1 (for 8-bit 2's complement) < 0
/* ... */
if (time_before(jiffies, timeout)) { /*
we did not time out, good ... */ }
else { /* we timed out, error ... */ }
So this code can be written as
11. 13
HARDWARE CLOCKS &
TIMERS
Architectures provide two hardware
devices to help with time keeping
1.Real-Time Clock –
The real-time clock (RTC) provides a
nonvolatile device for storing the system
time
On boot, the kernel reads the RTC and
uses it to initialize the wall time, which is
stored in the xtime variable
2.System Timer –
The idea behind the system time is—to
provide a mechanism for driving an
interrupt at a periodic rate
2 way to implement System Timer-
1. Electronic clock –
oscillates at a programmable frequency
2. Counter –
Set to some initial value and decrements at a
fixed rate until the counter reaches zero, an
interrupt is
triggered.
On x86,
the primary system timer is the
programmable interrupt timer (PIT)
Other include the local APIC timer and the
processor’s time stamp
counter (TSC).
12. 13
HARDWARE CLOCKS &
TIMERS
Real-Time Clock (RTC): All PCs include a clock called Real Time Clock(RTC),
which is independent of the CPU and all other
chips.
The RTC continues to keep track of time even
when the system is off by way of a small battery
typically included on the system board. On the PC
architecture, the RTC and the
CMOS are integrated, and a single battery keeps
the RTC running and the BIOS settings preserved.
On boot, the kernel reads the RTC and uses it to
initialize the wall time, which is stored in the
xtime variable.
The kernel does not typically read the value again;
however, some supported architectures, such as
x86, periodically save the current wall time back
to the RTC
13. 13
HARDWARE CLOCKS &
TIMERS
Linux uses the RTC only to derive the time
and date; however, it allows processes to
program the RTC by acting on the
/dev/rtc device file
The RTC is capable of issuing periodic
interrupts on IRQ 8 at frequencies ranging
between 2 Hz and 8,192 Hz.
It can also be programmed to activate the
IRQ 8 line when the RTC reaches a specific
value, thus working as an alarm clock.
The kernel accesses the RTC through the
0x70 and 0x71 I/O ports.
Nonetheless, the real time clock’s primary
importance is only during boot, when the
xtime variable is initialized.
The “xtime” variable
The Original Representation-
The simplest data structure is time_t , defined in the
header <time.h>
On most Unix systems—Linux included—the type is
a simple typedef to the C long type:
typedef long time_t;
#include <sys/time.h>
struct timeval
{
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
The timespec data structure is defined in
<linux/time.h> as:
struct timespec
{
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
Real-Time Clock (RTC):
14. 13
HARDWARE CLOCKS &
TIMERSThe “xtime” variable
The xtime variable stores the current time
and date; it is a structure of type
timespec having two fields:
tv_sec-
Stores the number of seconds that have
elapsed since midnight of January 1, 1970
(UTC)
This date is called the epoch(reference
date). Most Unix systems base their
notion of the
current wall time as relative to this epoch.
tv_nsec
Stores the number of nanoseconds that
have elapsed within the last second (its
value ranges between 0 and 999,999,999)
second.
The “xtime” variable
user programs get the current time and date
from the xtime variable.
The kernel also often refers to it, for instance,
when updating i-node timestamps.
The xtime variable is usually updated once in a
tick, that is, roughly 1000 times per The
xtime_lock seqlock avoids the race conditions
that could occur due to concurrent
accesses to the xtime variable. Remember that
xtime_lock also protects the jiffies_64
variable; in general, this seqlock is used to define
several critical regions of the timekeeping
architecture.
15. 13
HARDWARE CLOCKS &
TIMERSHow We See Time?
Some of the functions that we will cover convert between Unix time and strings, or programmatically
build a string representing a given date. To facilitate this process, the C standard provides the tm
structure for representing “broken-down” time in a more human-readable format. This structure is
also defined in <time.h> :
16. 13
HARDWARE CLOCKS &
TIMERSSystem Timer
kernel uses system timer to gauge the passing of time.
This system timer works off of an electronic time source, such as a digital clock or the frequency
of the processor.
The system timer goes off (often called hitting or popping) at a pre programmed
frequency, called the tick rate.
When the system timer goes off, it issues an interrupt that the kernel handles via a special
interrupt handler.
Because the kernel knows the pre programmed tick rate, it knows the time between any two
successive timer interrupts . This period is called a tick and is equal to 1/(tick rate) seconds.
This is how the kernel keeps track of both wall time and system uptime.
On x86, the primary system timer is the programmable interrupt timer (PIT).
The kernel programs the PIT on boot to drive the system timer interrupt (interrupt zero) at
HZ frequency.
17. 124
TIMER INTERRUPT HANDLER
The timer interrupt is broken into two pieces
interrupt handler – Architecture Depedent
tick_periodic() – Architecture independent routine
Task of Interrupt handler –
1. Obtain the xtime_lock lock, which
protects access to jiffies_64 and the wall
time value, xtime.
2. Acknowledge or reset the system timer
as required.
3. Periodically save the updated wall time
to the real time clock.
4. Call the architecture-independent timer
routine, tick_periodic().
Task of Tick Periodic()
1. Increment the jiffies_64 count by one.
2. Update resource usages, such as consumed
system and user time, for the currently
3. running process.
4. Run any dynamic timers that have expired
(discussed in the following section).
5. Execute scheduler_tick(), as discussed in
Chapter 4
6. Update the wall time, which is stored in
xtime.
7. Calculate the infamous load average.
18. 124
TIMER INTERRUPT HANDLER
The routine is simple because other functions handle most of the work:
static void tick_periodic(int cpu)
{
if (tick_do_timer_cpu == cpu) {
write_seqlock(&xtime_lock);
/* Keep track of the next tick event */
tick_next_period = ktime_add(tick_next_period, tick_period);
do_timer(1);
write_sequnlock(&xtime_lock);
}
update_process_times(user_mode(get_irq_regs()));
profile_tick(CPU_PROFILING);
}
Most of the important work is enabled in
do_timer() and
update_process_times() .
The former is responsible for actually performing the
increment to jiffies_64 :
void do_timer(unsigned long ticks)
{
jiffies_64 += ticks;
update_wall_time();
calc_global_load();
}
update_wall_time() - updates the
wall time in accordance with the
elapsed ticks, whereas
calc_global_load() -updates the
system’s load average statistics.
19. 125
TIMER
Timers are not cyclic.The timer is
destroyed after it expires
Timers are represented by struct
timer_list, which is defined in
<linux/timer.h>:
struct timer_list {
struct list_head entry; /* entry in linked list
of timers */
unsigned long expires; /* expiration value,
in jiffies */
void (*function)(unsigned long); /* the
timer handler function */
unsigned long data; /* lone argument to
the handler */
struct tvec_t_base_s *base; /* internal
timer field, do not touch */
};
Timers —
sometimes called dynamic timers or
kernel timers—are essential for
managing the flow of time in kernel
code. Kernel code often needs to delay
execution of some function
until a later time.
A timer is easy to use.
You perform some initial setup,
specify an expiration time ,Specify a
function to execute upon said
expiration, and activate the timer.
The given function runs after the timer
expires.
20. 125
TIMER
UsingTimers
4. Finally, you activate the timer:
add_timer(&my_timer);
Sometimes you might need to modify the
expiration of an already active timer
mod_timer(&my_timer, jiffies + new_delay); /*
new expiration */
If you need to deactivate a timer prior to its
expiration,use the del_timer() function:
del_timer(&my_timer);
To deactivate the timer and wait until a potentially
executing handler for the timer exits, use
del_timer_sync():
del_timer_sync(&my_timer);
1. The first step in creating a timer is defining it:
struct timer_list my_timer;
2. the timer’s internal values must be initialized
init_timer(&my_timer);
3. Now you fill out the remaining values as
required:
my_timer.expires = jiffies + delay; /* timer
expires in delay ticks */
my_timer.data = 0; /* zero is passed to the
timer handler */
my_timer.function = my_function; /*
function to run when timer expires */
21. 125
TIMER
Timer Race Conditions
Because timers run asynchronously with respect to
the currently executing code, several potential race
conditions exist.
First
never do the following as a substitute for a mere
mod_timer(), because this is unsafe on
multiprocessing machines:
del_timer(my_timer)
my_timer->expires = jiffies + new_delay;
add_timer(my_timer);
Second
Second, in almost all cases, you should use
del_timer_sync() over del_timer().
Timer Implementation
The kernel executes timers in bottom-half context, as
softirqs, after the timer interrupt
completes.
The timer interrupt handler runs update_process_times(),
which calls
run_local_timers():
void run_local_timers(void)
{
hrtimer_run_queues();
raise_softirq(TIMER_SOFTIRQ); /* raise the timer softirq */
softlockup_tick();
}
22. 126
DELAYING EXECUTION
Need for busy looping
1. When we want a delay, while using hardware
like (NIC for the first time ).
Implementation in case of first point:
unsigned long timeout = jiffies + 10; /* ten ticks */
while (time_before(jiffies, timeout)) ;
Problem in above solution :
spinning in a silly loop—because no useful work is
accomplished!!!
Second Solution (Better solution)
while (time_before(jiffies, delay))
cond_resched(); (New process is scheduled)
Busy Looping 3.When we wan't to solve critical section problem
through semaphores....
s=1;
P1 P2
---- ----
---- ----
Wait(s) Wait(s) // Busy Looping
Critial Section Critical Section
Signal(s) Signal(s)
---- ----
---- ----
Code of Wait(s) Code of Signal(s)
{ {
while(s<=0); s=s+1;
s=s-1; }
}`
23. 126
DELAYING EXECUTION
for Hz = 100 we can not provide time delay
less than 10 ms
even
for Hz= 1000 we can not provide time
delay less than 1 ms
so for smaller delay ....
kernel provides three functions for
microsecond, nanosecond, and millisecond
delays, defined in <linux/delay.h> and
<asm/delay.h>, which do not use
jiffies:
void udelay(unsigned long usecs)
void ndelay(unsigned long nsecs)
void mdelay(unsigned long msecs)
Small Delays-
BOGOMips
Its name is a contraction of bogus
(that is, fake) and MIPS (million of instructions per second).
Everyone is familiar with a boot
message similar to the following (this is on a 2.4GHz 7300-series
Intel Xeon):
Detected 2400.131 MHz processor.
Calibrating delay loop... 4799.56 BogoMIPS
This value is stored in the loops_per_jiffy variable and is readable
from
/proc/cpuinfo
BOGOMips
24. 126
DELAYING EXECUTION
This call puts your task to sleep until at least the specified time has elapsed.
When the specified time has elapsed, the kernel wakes the task up and
places it back on the runqueue.
/* set task’s state to interruptible sleep */
set_current_state(TASK_INTERRUPTIBLE);
/* take a nap and wake up in “s” seconds */
schedule_timeout(s * HZ);
Sleeping on a Wait Queue, with a Timeout -
Sometimes it is desirable to wait for a specific event or wait for a specified time to
elapse—whichever comes first.
schedule_timeout()-
26. 12
SYSTEM CALLS
A System call is the programmatic way in
which a computer program requests a
service from the kernel of the operating
system it is executed on.
System calls of timer has
#include<sys/time.h> header file.
System Call Current time of day
TIME(): get time in seconds
SETTIMEOFDAY(): set time as well as time zone
GETTIMEOFDAY(): get time as well as time zone
SLEEP(): process can sleep for s seconds.
CLOCK_SETTIME(): set the time of the specified
clock
CLOCK_GETTIME(): get the time of the specified
clock
CLOCK_GETRES(): get resolution of specified
clock
CLOCK_ADJTIME(): tune the specified clock
POSIX clocks
7
27. 125
TIMER
Clocks-based timers Timers
ALARM(): set an alarm clock for delivery of a signal
SETTIMER(): set value of an interval timer
GETTIMER(): get value of an interval timer
TIMER_CREATE(): create a POSIX pre-process timer
TIMER_DELETE(): delete a POSIX and pre-process
timer
TIMER_SETTIME(): arm/disarm POSIX and pre-
process timer
TIMER_GETTIME(): fetch state of POSIX and pre-
process timer