Inside The RT Patch Steven Rostedt (Red Hat) Darren V Hart (IBM) Talk: Benchmarks :

Slides:



Advertisements
Similar presentations
Copyright © 2000, Daniel W. Lewis. All Rights Reserved. CHAPTER 8 SCHEDULING.
Advertisements

Resource management and Synchronization Akos Ledeczi EECE 354, Fall 2010 Vanderbilt University.
Tutorial 3 - Linux Interrupt Handling -
Bilgisayar Mühendisliği Bölümü GYTE - Bilgisayar Mühendisliği Bölümü Multithreading the SunOS Kernel J. R. Eykholt, S. R. Kleiman, S. Barton, R. Faulkner,
CS533 Concepts of Operating Systems Class 4 Linux Kernel Locking Issues.
CS510 Concurrent Systems Class 1
Supporting Time-sensitive Application on a Commodity OS By Ashvin Goel, Luca Abeni, Charles Krasic, Jim Snow, Jonathan Walpole Presenter: Shuping Tien.
CPS110: Implementing threads/locks on a uni-processor Landon Cox.
Race Conditions CS550 Operating Systems. Review So far, we have discussed Processes and Threads and talked about multithreading and MPI processes by example.
Threads CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
The Design of Robust and Efficient Microkernel ManRiX, The Design of Robust and Efficient Microkernel Presented by: Manish Regmi
1 Previous lecture review n Out of basic scheduling techniques none is a clear winner: u FCFS - simple but unfair u RR - more overhead than FCFS may not.
Linux and Real Time Real-time systems are characterized by deadlines. When a missed deadline results in inconvenience or a diminished customer experience,
Chapter 5 – CPU Scheduling (Pgs 183 – 218). CPU Scheduling  Goal: To get as much done as possible  How: By never letting the CPU sit "idle" and not.
Fast Multi-Threading on Shared Memory Multi-Processors Joseph Cordina B.Sc. Computer Science and Physics Year IV.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion.
Cpr E 308 Spring 2004 Real-time Scheduling Provide time guarantees Upper bound on response times –Programmer’s job! –Every level of the system Soft versus.
Unit - VI. Linux and Real Time: Real Time Tasks Hard and Soft Real Time Tasks Linux Scheduling Latency Kernel Preemption Challenges in Kernel Preemption.
Scheduling Lecture 6. What is Scheduling? An O/S often has many pending tasks. –Threads, async callbacks, device input. The order may matter. –Policy,
Fall 2013 SILICON VALLEY UNIVERSITY CONFIDENTIAL 1 Introduction to Embedded Systems Dr. Jerry Shiao, Silicon Valley University.
CSE 451: Operating Systems Section 5 Midterm review.
Kernel Locking Techniques by Robert Love presented by Scott Price.
CPS110: Implementing threads Landon Cox. Recap and looking ahead Hardware OS Applications Where we’ve been Where we’re going.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
1 Review of Process Mechanisms. 2 Scheduling: Policy and Mechanism Scheduling policy answers the question: Which process/thread, among all those ready.
4300 Lines Added 1800 Lines Removed 1500 Lines Modified PER DAY DURING SUSE Lab.
CSCI1600: Embedded and Real Time Software Lecture 9: Input Output Concepts Steven Reiss, Fall 2015.
Real Time System with MVL. © 2007 MontaVista Confidential | Overview of MontaVista Agenda Why Linux Real Time? Linux Kernel Scheduler Linux RT technology.
Managing Processors Jeff Chase Duke University. The story so far: protected CPU mode user mode kernel mode kernel “top half” kernel “bottom half” (interrupt.
1.  System Characteristics  Features of Real-Time Systems  Implementing Real-Time Operating Systems  Real-Time CPU Scheduling  An Example: VxWorks5.x.
CSC 660: Advanced Operating SystemsSlide #1 CSC 660: Advanced OS Synchronization.
Low Overhead Real-Time Computing General Purpose OS’s can be highly unpredictable Linux response times seen in the 100’s of milliseconds Work around this.
Where Testing Fails …. Problem Areas Stack Overflow Race Conditions Deadlock Timing Reentrancy.
Interrupt Handler Migration and Direct Interrupt Scheduling for Rapid Scheduling of Interrupt-driven Tasks Reviewer: Kim, Hyukjoong ESLab.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
CPS110: Implementing threads on a uni-processor Landon Cox January 29, 2008.
Copyright © 2010 K Computing Use of RT-Preempt Kevin Dankwardt, Ph.D. K Computing
6.1 Silberschatz, Galvin and Gagne ©2005 Operating System Principles 6.5 Semaphore Less complicated than the hardware-based solutions Semaphore S – integer.
Inside The RT Patch Steven Rostedt (Red Hat) Darren V Hart (IBM) Talk: Benchmarks :
Real Time Linux Who Needs It? Presented by: Steven Rostedt
Tutorial 2: Homework 1 and Project 1
Inside The RT Patch Steven Rostedt (Red Hat) Darren V Hart (IBM) Talk: Benchmarks :
Introduction to Real-Time Operating Systems
REAL-TIME OPERATING SYSTEMS
Introduction to Operating Systems
Linux Realtime Preemption and Its Impact on ULDD* - Progress Report -
CS 6560: Operating Systems Design
CS703 – Advanced Operating Systems
Realtime Linux Clark Williams Tech Lead
Anton Burtsev February, 2017
Semester Review Chris Gill CSE 422S - Operating Systems Organization
Linux Synchronization
Kernel Synchronization II
HW & Systems: Operating Systems IS 101Y/CMSC 101 Computational Thinking and Design Tuesday, October 22, 2013 Carolyn Seaman University of Maryland, Baltimore.
Real-Time Operating Systems
Lecture 2 Part 2 Process Synchronization
Fast Communication and User Level Parallelism
CSE 451: Operating Systems Autumn 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 596 Allen Center 1.
CS510 Concurrent Systems Class 1a
CSE 451: Operating Systems Autumn 2001 Lecture 2 Architectural Support for Operating Systems Brian Bershad 310 Sieg Hall 1.
February 5, 2004 Adrienne Noble
Thomas E. Anderson, Brian N. Bershad,
Supporting Time-Sensitive Applications on a Commodity OS
CSE 451: Operating Systems Winter 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 412 Sieg Hall 1.
Linux Kernel Locking Techniques
Interrupts and Interrupt Handling
CSE 153 Design of Operating Systems Winter 2019
CS 5204 Operating Systems Lecture 5
Linux Scheduling CSE 2431: Introduction to Operating Systems
Presentation transcript:

Inside The RT Patch Steven Rostedt (Red Hat) Darren V Hart (IBM) Talk: Benchmarks :

Inside The RT Patch Steven Rostedt (Red Hat) Darren V Hart (IBM) Talk: Benchmarks :

Understanding PREEMPT_RT Steven Rostedt (Red Hat) Darren V Hart (IBM) Talk: Benchmarks :

Understanding PREEMPT_RT Steven Rostedt (Red Hat) Darren V Hart (Intel) Talk: Benchmarks :

Understanding PREEMPT_RT Steven Rostedt (Red Hat) Darren V Hart (Intel) Talk: Benchmarks :

ELC-EU ●

So what should I talk about?

Wikimedia Commons

Trebuchet Wikimedia Commons

Trebuchet Wikimedia Commons

Trebuchet

Where to get the RT patch ● Stable Repository – git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git ● Patches – ● Wiki –

What is a Real-time OS? ● Deterministic – Does what you expect to do – When you expect it will do it ● Does not mean fast – Would be nice to have throughput – Guarantying determinism adds overhead – Provides fast “worst case” times ● Can meet your deadlines – If you have done your homework

What is a Real-time OS? ● Dependent on the system – SMI – Cache – Bus contention ● hwlat detector – New enhancements coming

The Goal of PREEMPT_RT ● 100% Preemptible kernel – Not actually possible, but lets try regardless – Remove disabling of interrupts – Removal of disabling other forms of preemption ● Quick reaction times! – bring latencies down to a minimum

Menuconfig

No Preemption ● Server – Do as most possible with as little scheduling overhead ● Never schedule unless a function explicitly calls schedule() ● Long latency system calls. ● Back in the days of 2.4 and before.

Voluntary Preemption ● might_sleep(); – calls might_resched(); calls _cond_resched() – Used as a debugging aid to catch functions that might schedule called from atomic operations. – need_resched – why not schedule? – schedule only at “preemption points”.

Preemptible Kernel ● Robert Love's CONFIG_PREEMPT ● SMP machines must protect the same critical sections as a preemptible kernel. ● Preempt anywhere except within spin_locks and some minor other areas (preempt_disable). ● Every spin_lock acts like a single “global lock” WRT preemption.

Preemptible Kernel (Basic RT) ● Mostly to help out debugging PREEMPT_RT_FULL ● Enables parts of the PREEMPT_RT options, without sleeping spin_locks ● Don't worry about it (It will probably go away)

Fully Preemptible Kernel The RT Patch ● PREEMPT_RT_FULL ● Preempt everywhere! (except from preempt_disable and interrupts disabled). ● spin_locks are now mutexes. ● Interrupts as threads – interrupt handlers can schedule ● Priority inheritance inside the kernel (not just for user mutexes)

Sleeping spin_lock ● CONFIG_PREEMPT is a global lock (like the BKL but for the CPU) ● sleeping spin_locks contains critical sections that are localized to tasks ● Must have threaded interrupts ● Must not be in atomic paths (preempt_disable or local_irq_save) ● Uses priority inheritance – Not just for futexes

PREEMPT_LAZY ● RT can preempt almost anywhere ● Spinlocks that are now mutexes can be preempted – Much more likely to cause contention ● Do not preempt on migrate_disable() – used by sleepable spinlocks ● Increases throughput on non-RT tasks

Priority Inheritance ● Prevents unbounded priority inversion – Can't stop bounded priority inversion ● Is a bit complex – One owner per lock – Why we hate rwlocks ● will explain more later

Unbounded Priority Inversion preempted A B C blocked

Priority Inheritance preemptedreleases lock A B C wakes up blockedsleeps

raw_spin_lock ● Some spin_locks should never be converted to a mutex ● Same as current mainline spin_locks ● Should only be used for scheduler, rtmutex implementation, debugging/tracing infrastructure and for timer interrupts. ● Timer drivers for clock events (HPET, PM timer, TSC) ● Exists today in current mainline, with no other purpose as to annotate what locks are special (Thank you Linus!)

Threaded Interrupts ● Lowers Interrupt Latency ● Prioritize interrupts even when the hardware does not support it. ● Less noise from things like “updatedb”

Interrupt Latency Task interrupt device handler

Interrupt Thread Task interrupt device handler sleep wake up device thread

Non-Thread IRQs ● Timer interrupt – Manages the system (sends signals to others about time management) ● IRQF_TIMER – Denotes that a interrupt handler is a timer ● IRQF_NO_THREAD – When the interrupt must not be a thread – Don't use unless you know what you are doing – Must not call spin_locks

Threaded Interrupts ● Now in mainline – Per device interrupts – One big switch (all irqs as threads) ● Per device is still preferred – except for non shared interrupts – Shared devices can have different priorities ● One big switch – Handlers the same, but just threaded

Threaded Interrupts ● request_threaded_irq() – Tells system driver wants handler as thread ● Driver registers two functions – handler ● If NULL must have thread_fn – Disables irq lin – handler assigned by system ● non-NULL is called by hard irq – thread_fn (optional) ● When set makes irq threaded ● non-NULL to disable device only

Threaded Interrupts ● The kernel command line parameter – threadirqs ● threadirqs forces all IRQS to have a “special” handler” and uses the handler as thread_fn – except IRQF_NOTHREAD, IRQF_PER_CPU and IRQF_ONESHOT

local_irq_disable ● EVIL!!! ● This includes local_irq_save ● No inclination to what it's protecting ● SMP unsafe ● High latency

spin_lock_irqsave ● The Angel NOT ● PREEMP_RT does NOT disable interrupts – Remember, in PREEMPT_RT spin_locks are really mutexes – low latency ● Tight coupling between critical sections and disabling interrupts ● Gives a hint to what it's protecting – (spin_lock name)

preempt_disable ● local_irq_disable's younger sibling ● Also does not give a hint to what it protects ● preempt_enable_no_resched – only should be used within preempt_disabled locations – __preempt_enable_no_resched ● Only use before directly calling schedule()

per_cpu ● Avoid using: – local_irq_save – preempt_disable – get_cpu_var (well, you can, but be nice – it calls preempt_disable) ● Do: – pinned CPU threads – get_cpu_light() – get_local_var(var) – local_lock[_irq[save]](var)

get_cpu_light() ● Non PREEMPT_RT is same as get_cpu() ● On PREEMPT_RT disables migration

get_local_var(var) ● Non PREEMPT_RT is same as get_cpu_var(var) ● On PREEMPT_RT disables migration

local_lock[_irq[save]](var) ● Non PREEMPT_RT is just preempt_disable() ● On PREEMPT_RT grabs a lock based on var – disables migration ● Use local_unlock[_irq[restore]](var) ● Labels what you are protecting

rwlocks ● Death of Determinism ● Writes must wait for unknown amount of readers ● Recursive locking ● Possible strange deadlock due to writers – Yes, affects mainline too!

NOHZ ● idle nohz best for power management ● Not nice for responses from idle ● Process nohz coming soon (nothing to do with idle nohz, but uses same ideas and in some cases, same code)

Real-Time User Space ● Don't use priority 99 ● Don't implement spin locks – Use priority inheritance futexes – PTHREAD_PRIO_INHERIT ● Avoid slow I/O ● mmap passing data ● mlock_all() – at least the stuff you know you need

Questions?