Click to edit the title text format,Click to edit the outline text format,Second Outline Level,Third Outline Level,Fourth Outline Level,Fifth Outline Level,Sixth Outline Level,Seventh Outline Level,Eighth Outline Level,Ninth Outline Level,*,A Brief History of Real-Time Linux,Sven-Thorsten Dietrich,Montavista Software,Inc.,EB II Room 1226,April 12,2006:1:50-2:45,Raleigh,NC,Real Time Overview,Real-Time Linux Background,Real-Time Linux Evolution,Real-Time Linux Enablers,Real-Time Inhibitors,Interrupt Latency,Kernel Locking,Legacy Locking,Real-Time Kernel,Interrupt Handlers,PI Mutex,Performance/Benchmarks,Acceptance,Virtualization,2,Evolution of Linux,Early Linux Not Designed for Real-Time Processing,Early Linux(1.x Kernel)installations on retired Windows PCs,Old/Obsolete hardware useful under Linux due to efficiency of O/S,Linux outperformed Windows in reliability and uptime(still does),Linux Design:Fairness,Throughput and Resource-Sharing,Basic Unix development design principles applied in Kernel,Heavily(over)-loaded systems continue to make progress,Does not drop network connections or starve users/applications,Fairness-and Resource-Sharing Design is Linuxs Strength,contributed to make Linux competitive and popular in the enterprise-server and development-application environments,Gave rise to RedHat and others.,Essential to the evolution of Linux,endemic of UNIX legacy,3,Why Linux in Real-Time Systems?,Not because of the Kernels Real-Time Performance!,UNIX-legacy Operating Systems were designed with operating principles focused on,throughput,and,progress,User tasks should not stall under heavy load,System resources must be shared fairly between users,Fairness,progress and resource-sharing conflict with the requirements of time-critical applications,VIP vs.General Admission,UNIX systems(and Linux)are historically not Real-Time OS,Linux has lagged many commercial Unixs in Real-Time performance-enhancement and Real-Time capabilities,Solaris,LynxOS,QNX,SCO,4,Why Real-Time in Linux Systems(Embedded),Most Important Factors Inhibiting Linux Adoption,Data from VDC,“Linuxs Future in the Embedded Systems Market,June 2004,5,Real-Time in Handheld&Embedded Systems,Cost/Performance/Power/Weight Compromise,Competitive,High-Volume,Low-margin Markets,Maximum Feature-set,Add-ons,Responsive UI feel,Device specs:minimal CPU&Memory&Battery Powered,Minimal CPU=High CPU utilization,High CPU load+Time-Critical functionality,RT specs,Real-time Requirements will,never,be alleviated by Improvements in Hardware Performance/Efficiency,Software utilizing latest hardware technologies easily keep up with,and usually out-paces,advances in hardware technology,If you dont believe that,go shopping(for a mobile phone),6,Real-Time Linux 2.6 Enablers,Pro-Audio Performance Requirements,Audio Community Involved in Kernel-Preemption since 2.2,Audio Community strongly Endorsing RT technology,Embedded Application Domain,Single-Chip,Mobile Applications(Wireless/Cellular Handsets),Predictable OS performance eliminates HW design uncertainty,Reliable Prototyping and Improved Product Scheduling,Multimedia Carrier(QOS)Application Domain,Telephony,Audio/Video/Multimedia/Home Entertainment,Fine-Granular Preemption improves SMP scalability,Mainstreaming of SMP Technology,Dual/Quad/Octa-Core Intel,AMD,PPC,Arm,7,Real-Time and Linux Kernel Evolution,Gradual Kernel Optimizations over Time,SMP Critical sections(Linux 2.x),Low-Latency Patches(Linux 2.2),Preemption Points/Kernel Tuning(Linux 2.2/2.4),Preemptible Kernel Patches(Linux 2.4),Fixed-time“O(1)Scheduler(Linux 2.6),Voluntary Preemption(Linux 2.6),In 2003-04 Linux 2.6 RT Technology Regressed,Early Linux 2.6 Real-Time Performance was worse than 2.4 Kernel Performance,Audio Community and others balked at moving to 2.6 Kernel Base,What Happened?,8,Real-Time Inhibitor:Critical Section Locking,Linux 2.6 Kernel Critical Sections are Non-Preemptible,Critical sections protect shared resources,e.g.hardware registers,I/O ports,and data in RAM,Critical sections are shared by Processes,Interrupts and CPUs.,Effective protection is provided by the Spin-Lock Subsystem,Critical sections must be locked and unlocked,Locked critical sections are not preemptible,Linux 2.6 Kernel has 11,000 critical sections,Exhaustive Kernel testing to identify worst-case code paths,Labor-intensive cleanup of critical sections,No control over 3,rd,party drivers,Worst-case after cleanup still not acceptable,Maintenance,community education,policing/regression testing,9,Real-Time Inhibitor:Interrupt Handlers,Linux 2.6 Kernel:Unbounded IRQ subsystem latencies,Task-Preemption latency increases with hardware-interrupt load,Interrupts cannot be preempted,No Priorities for Interrupts,IRQ Subsystem always preempts tasks unconditionally,Unbounded SoftIRQ subsystem(“Bottom Half Processing),Activated by HW IRQs(Timers,SCSI,Network),SoftIRQs re-activate,iterate,Driver-level adaptations,Network Driver NAPI adaption reduces D.o.S.effects of high packet loads,10。