《brief history of real-time linux - linux world》由會(huì)員分享,可在線閱讀,更多相關(guān)《brief history of real-time linux - linux world(34頁珍藏版)》請?jiān)谘b配圖網(wǎng)上搜索。
1、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,M
2、ontavista 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/Be
3、nchmarks,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),Lin
4、ux 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 m
5、ake 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 Sys
6、tems 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 Admissi
7、on,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
8、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
9、,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
10、 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
11、 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 In
12、tel,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(
13、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-
14、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 ar
15、e 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/regressio
16、n 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