element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Embedded and Microcontrollers
  • Technologies
  • More
Embedded and Microcontrollers
Embedded Forum 基于APIC时钟的嵌入式Linux内核实时化研究
  • Blog
  • Forum
  • Documents
  • Quiz
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Embedded and Microcontrollers to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 0 replies
  • Subscribers 478 subscribers
  • Views 164 views
  • Users 0 members are here
  • 嵌入式
  • embedded
  • linux内核
  • apic时钟
  • 实时化
Related

基于APIC时钟的嵌入式Linux内核实时化研究

laidandan
laidandan over 15 years ago

引言

 

嵌入式Linux是指对Linux进行剪裁后,将其固化在单片机或者存储器中,应用于特定场合的专用Linux系统。嵌入式系统要求实时性能高,但Linux为分时系统设计的操作系统,尽管最新的内核在实时性能方面有所提高,但它仍然不是一个实时系统,在很多场合不能满足实时性要求。一般地,通过改造Linux的内核以提高其实时性能有2种策略:一种是采用底层编程的方法对Linux内核进行修改(如调度算法、时钟修改等),典型的系统有Kansas大学开发的KURT。文献提出了抢占式内核调度算法,容易引起内核优先级翻转,文献针对非抢占式内核,增加抢占点,该方法需要优秀的调度算法。另一种途径是Linux的外部实时性扩展,在原有Linux基础上再设计一个用于专门处理实时进程的内核,典型的系统有RTLinux、RTAI等。此方法的不足是RTLinux现在已经停止了更新,目前的开源版本仅支持2.4内核,RTAI的设计原理和RTLinux类似,也是一个实时性应用接口。本文采用APIC时钟修改的方法对Linux内核进行实时化改造,修改APIC中断函数,将APIC中断和8254中断排序,使得硬实时中断的优先级大于普通8254中断。通过多组仿真实验,验证了该改造方法是有效的。

1 嵌入式Linux的实时性分析

 

Linux设计的初衷是系统吞吐量的平衡,其内核试图通过一种公平分配的策略来实现各进程平均地共享系统资源:

 

(1)内核的不可抢占性:Linux的内核在单处理器上不可抢占,当一个任务进入内核态运行时,一个具有更高优先级的进程,只有等待处于核心态的系统调用返回后方能执行,这将导致优先级逆转。

 

(2)进程调度的不可抢占性:Linux作为一个分时系统,采用多级反馈轮转调度算法,它保证了每一个进程都有一种调度策略,但是都放在同一个队列中运行,这也是Linux作为实时操作系统的一个弱点。图1是Linux调度机制框图。

 

(3)时钟中断的精度不高:Linux 2.4.X内核的时钟中断周期为10 ms,时钟粒度太过于粗糙,不能满足实时性要求。

 

(4)Linux的虚拟存储管理:Linux采用段和页机制的虚拟存储管理技术,进程在硬盘和内存间的换入换出必然带来额外的开销,造成很大的延迟。

image
由此可见,要将Linux应用于嵌入式系统,必须对其进行实时化改造,以适应嵌入式领域要求。

2 基于时钟修改的内核改造方案

 

在单CPU系统中,与时间有关的活动都是由8254时钟芯片来驱动的,8254产生0号中断。直接修改内核定时参数HZ的初值就可构造细粒度定时器。这种方式实现起来很简单,但是由此带来频繁的定时中断使得系统的开销很大,当然随着硬件速度的提高,这种开销会逐步降低。

 

简单地修改赫兹参数HZ进行实时化的方法显然并不可取。Linux 2.6内核的时钟粒度是1 ms,但仍然与嵌入式领域的实时化要求差距较远,因此需要更高精度的时钟。目前常见的修改时钟系统达到实时化的方法都是从软件层面着手,这方面己获得较大进展,但是从时钟系统的硬件结构分析并开展实时化工作也是一个值得注意的方向。本文利用先进的APIC时钟实现一个高精度时钟系统,提供了高精度的中断响应,从而以较少的改动获得较高的实时性。

 

APIC以总线频率工作,可立即执行所有的定时器操作,目前x86都有片内APIC,用户可在单CPU内使用APIC。APIC除了能提供高精度的时钟外还具有一个重要的优点,是由于它位于片内,对其编程只需几个CPU指令周期,而对IntelX86的8254存取需要若干慢速的ISA总线指令。

 

在100MHz的CPU系统中,处理一个中断的时间不到10μs,因此高速CPU完全可在更短的时间内处理更多的APIC中断。理论上APIC可实现10 ns左右的系统时钟,但实际上在处理中断时要耗费一些时间,因此中断的响应时间要大于10 ns。

 

APIC本身提供了中断处理函数apic_timer_interrupt,该函数包括Irq_enter(),Run_realtimer_queue()和irq_exit(),其中函数irq_ exit通常负责判断当前是否有8254产生的软中断存在,如果存在,就会触发8254软中断,这样会造成APIC硬中断处理延迟。本文的思路就是修改irq_exit,在其中将各软中断线程和硬中断线程进行排序,使APIC硬中断的优先级高于软中断,此时硬中断线程得到优先处理,从而提高内核的实时性能。Irp_exit函数的核心代码如下:
image

 

上面调用invoke_softirq()函数执行软中断使本文修改的重点,修改中断向量表,对向量表中所有软中断和实时中断进行排序,提前硬中断的时间片,这样使当前处于pending状态的软中断被屏蔽和悬挂,直到硬中断处理完成为止。将invoke_softirq()函数修改为:
image

 

每个处理器时间片上能够处理的中断只有一个,通过更新当前任务时间片,使硬中断在第一时间获得CPU的响应,此时软中断将被屏蔽,这就保证了硬中断能够得到实时的响应。
由于Linux采用8254完成时序分配,8254需要保留以保证系统的稳定性。这样的话,8254定时器和APIC必须共存,对于硬实时应用,可采用APIC时钟进行计时。在8254中断过程中,如果产生APIC中断,采用通过本文的方珐必须对优先对APIC时钟进行响应,会出现8254中断被抢占,此时上下文切换等操作可能导致不可预料的错误。解决问题的方法可采取在APIC相应中断期间,关闭软中断,只有当APIC中断执行完毕后,8254软中断才能够被响应。

3 实时性能测试与分析

 

实验条件1:CPU:PⅢ300 MHz,内存为128 MB,硬盘为5 400转的15 GB台式机硬盘,操作系统为Fedora2.6.18内核。环境一(vd-d1)采用原版内核,环境二(vd-d2)采用改进型内核。测试方法为通过测试内核的上、下文切换、内存延迟及模拟外部中断来评价改造前后的性能。统计测试结果,如图2、图3所示。

image
从实验结果可知,在上、下文切换中I/0读/写和文件打开和关闭,改进型内核的实时性能都有明显提高,模拟TCP通道子项,改进型内核性能提高了约6倍,但在对中断响应要求不是很高的null call测试中,中断响应时间几乎相同。改进型内核中断响应速度始终稳定在微妙级。在处理器负荷较轻时原始内核有着良好的内存延迟,随着处理器负荷的进一步加重,原始内核的内存延迟急剧增加。在最差情况下,系统响应速度较慢,延迟时间达到5μs。而改进型内核在处理器负荷变化时,系统的响应速度变化不明显,而且中断响应速度始终稳定在2μs以下,性能稳定。

 

实验条件2:采用改进型内核,环境一(vd-d2)CPU:PIII 300 MHz,环境二(vd-d3)CPU降频为200 MHz(接近ARM9)。统计测试结果,获得它们的文件系统延迟结果见图4。图4反映了同样采用改进型内核,将CPU降频前后,测试结果差距在10μs以内,可看出在文件系统延迟中,处理器频率的较小差距对内核的影响不大。如采用高主频的处理器,实验结果差距较大。
image

 

4 结语

 

本文通过修改APIC时钟,可显著地改进嵌入式系统的实时性能,通过对比试验可看出改进型内核具有良好的实时性能,满足了系统实时性和稳定性要求。本文方法使得嵌入式Linux系统在高实时性领域中得到实际的应用。

引言

嵌入式Linux是指对Linux进行剪裁后,将其固化在单片机或者存储器中,应用于特定场合的专用Linux系统。嵌入式系统要求实时性能高,但Linux为分时系统设计的操作系统,尽管最新的内核在实时性能方面有所提高,但它仍然不是一个实时系统,在很多场合不能满足实时性要求。一般地,通过改造Linux的内核以提高其实时性能有2种策略:一种是采用底层编程的方法对Linux内核进行修改(如调度算法、时钟修改等),典型的系统有Kansas大学开发的KURT。文献提出了抢占式内核调度算法,容易引起内核优先级翻转,文献针对非抢占式内核,增加抢占点,该方法需要优秀的调度算法。另一种途径是Linux的外部实时性扩展,在原有Linux基础上再设计一个用于专门处理实时进程的内核,典型的系统有RTLinux、RTAI等。此方法的不足是RTLinux现在已经停止了更新,目前的开源版本仅支持2.4内核,RTAI的设计原理和RTLinux类似,也是一个实时性应用接口。本文采用APIC时钟修改的方法对Linux内核进行实时化改造,修改APIC中断函数,将APIC中断和8254中断排序,使得硬实时中断的优先级大于普通8254中断。通过多组仿真实验,验证了该改造方法是有效的。

1 嵌入式Linux的实时性分析

 

Linux设计的初衷是系统吞吐量的平衡,其内核试图通过一种公平分配的策略来实现各进程平均地共享系统资源:

 

(1)内核的不可抢占性:Linux的内核在单处理器上不可抢占,当一个任务进入内核态运行时,一个具有更高优先级的进程,只有等待处于核心态的系统调用返回后方能执行,这将导致优先级逆转。

 

(2)进程调度的不可抢占性:Linux作为一个分时系统,采用多级反馈轮转调度算法,它保证了每一个进程都有一种调度策略,但是都放在同一个队列中运行,这也是Linux作为实时操作系统的一个弱点。图1是Linux调度机制框图。

 

(3)时钟中断的精度不高:Linux 2.4.X内核的时钟中断周期为10 ms,时钟粒度太过于粗糙,不能满足实时性要求。

 

(4)Linux的虚拟存储管理:Linux采用段和页机制的虚拟存储管理技术,进程在硬盘和内存间的换入换出必然带来额外的开销,造成很大的延迟。

image
由此可见,要将Linux应用于嵌入式系统,必须对其进行实时化改造,以适应嵌入式领域要求。

2 基于时钟修改的内核改造方案

 

在单CPU系统中,与时间有关的活动都是由8254时钟芯片来驱动的,8254产生0号中断。直接修改内核定时参数HZ的初值就可构造细粒度定时器。这种方式实现起来很简单,但是由此带来频繁的定时中断使得系统的开销很大,当然随着硬件速度的提高,这种开销会逐步降低。

 

简单地修改赫兹参数HZ进行实时化的方法显然并不可取。Linux 2.6内核的时钟粒度是1 ms,但仍然与嵌入式领域的实时化要求差距较远,因此需要更高精度的时钟。目前常见的修改时钟系统达到实时化的方法都是从软件层面着手,这方面己获得较大进展,但是从时钟系统的硬件结构分析并开展实时化工作也是一个值得注意的方向。本文利用先进的APIC时钟实现一个高精度时钟系统,提供了高精度的中断响应,从而以较少的改动获得较高的实时性。

 

APIC以总线频率工作,可立即执行所有的定时器操作,目前x86都有片内APIC,用户可在单CPU内使用APIC。APIC除了能提供高精度的时钟外还具有一个重要的优点,是由于它位于片内,对其编程只需几个CPU指令周期,而对IntelX86的8254存取需要若干慢速的ISA总线指令。

 

在100MHz的CPU系统中,处理一个中断的时间不到10μs,因此高速CPU完全可在更短的时间内处理更多的APIC中断。理论上APIC可实现10 ns左右的系统时钟,但实际上在处理中断时要耗费一些时间,因此中断的响应时间要大于10 ns。

 

APIC本身提供了中断处理函数apic_timer_interrupt,该函数包括Irq_enter(),Run_realtimer_queue()和irq_exit(),其中函数irq_ exit通常负责判断当前是否有8254产生的软中断存在,如果存在,就会触发8254软中断,这样会造成APIC硬中断处理延迟。本文的思路就是修改irq_exit,在其中将各软中断线程和硬中断线程进行排序,使APIC硬中断的优先级高于软中断,此时硬中断线程得到优先处理,从而提高内核的实时性能。Irp_exit函数的核心代码如下:
image

 

上面调用invoke_softirq()函数执行软中断使本文修改的重点,修改中断向量表,对向量表中所有软中断和实时中断进行排序,提前硬中断的时间片,这样使当前处于pending状态的软中断被屏蔽和悬挂,直到硬中断处理完成为止。将invoke_softirq()函数修改为:
image

 

每个处理器时间片上能够处理的中断只有一个,通过更新当前任务时间片,使硬中断在第一时间获得CPU的响应,此时软中断将被屏蔽,这就保证了硬中断能够得到实时的响应。
由于Linux采用8254完成时序分配,8254需要保留以保证系统的稳定性。这样的话,8254定时器和APIC必须共存,对于硬实时应用,可采用APIC时钟进行计时。在8254中断过程中,如果产生APIC中断,采用通过本文的方珐必须对优先对APIC时钟进行响应,会出现8254中断被抢占,此时上下文切换等操作可能导致不可预料的错误。解决问题的方法可采取在APIC相应中断期间,关闭软中断,只有当APIC中断执行完毕后,8254软中断才能够被响应。

3 实时性能测试与分析

 

实验条件1:CPU:PⅢ300 MHz,内存为128 MB,硬盘为5 400转的15 GB台式机硬盘,操作系统为Fedora2.6.18内核。环境一(vd-d1)采用原版内核,环境二(vd-d2)采用改进型内核。测试方法为通过测试内核的上、下文切换、内存延迟及模拟外部中断来评价改造前后的性能。统计测试结果,如图2、图3所示。

image
从实验结果可知,在上、下文切换中I/0读/写和文件打开和关闭,改进型内核的实时性能都有明显提高,模拟TCP通道子项,改进型内核性能提高了约6倍,但在对中断响应要求不是很高的null call测试中,中断响应时间几乎相同。改进型内核中断响应速度始终稳定在微妙级。在处理器负荷较轻时原始内核有着良好的内存延迟,随着处理器负荷的进一步加重,原始内核的内存延迟急剧增加。在最差情况下,系统响应速度较慢,延迟时间达到5μs。而改进型内核在处理器负荷变化时,系统的响应速度变化不明显,而且中断响应速度始终稳定在2μs以下,性能稳定。

 

实验条件2:采用改进型内核,环境一(vd-d2)CPU:PIII 300 MHz,环境二(vd-d3)CPU降频为200 MHz(接近ARM9)。统计测试结果,获得它们的文件系统延迟结果见图4。图4反映了同样采用改进型内核,将CPU降频前后,测试结果差距在10μs以内,可看出在文件系统延迟中,处理器频率的较小差距对内核的影响不大。如采用高主频的处理器,实验结果差距较大。
image

 

4 结语

 

本文通过修改APIC时钟,可显著地改进嵌入式系统的实时性能,通过对比试验可看出改进型内核具有良好的实时性能,满足了系统实时性和稳定性要求。本文方法使得嵌入式Linux系统在高实时性领域中得到实际的应用。

  • Sign in to reply
  • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube