基于Linux2.6内核的实时性增强方案设计

基于Linux2.6内核的实时性增强方案设计,第1张

Linux以其功能强大、源代码开放、支持多种硬件平台、模块化设计方案以及丰富的开发工具支持等特点广泛应用在嵌入式系统领域。作为嵌入式产品的 *** 作系统平台,具有较好的实时性、系统可靠性、任务处理随机性是系统追求的目标,目前商业嵌入式 *** 作系统实时性能可以满足嵌入式领域的需求,但由于其价格昂贵,应用受到了限制。而嵌入式Linux以其非常低廉的价格,可以大大地降低成本,逐渐成为嵌入式 *** 作系统的首选。但由于其在实时应用领域的技术障碍,要应用在嵌入式领域,还必须对Linux内核作必要的改进。本文以S3C2410+Linux作为移动机器人 *** 作平台,为了提高机器人任务处理的实时性,针对影响Linux OS实时性能的若干方面进行研究,并利用相应的解决方法基于标准Linux2.6内核加以实现,最后通过测试,验证了此改进方法的效果。

1 Linux内核实时性分析

1.1 Linux内核制约实时性的因素

衡量 *** 作系统实时性的指标主要有中断延迟和抢占延迟。嵌入式系统中很多实时任务是靠中断驱动的,中断事件必须在限定的时限内处理,否则将产生灾难性的后果。大多数实时系统都是处理一些周期性的或非周期性的重复事件,事件产生的频度就确定了任务的执行时限,因此每次事件发生时,相应的处理任务必须及时响应处理,否则将无法满足时限 。抢占延迟就反映了系统的响应及时程度。针对Linux内核,中断关闭及中断优先级执行机制、内核不可抢占性、自旋锁(spinlock)及大内核锁及一些O(n)的任务调度算法影响了系统的实时性能。

1.2 现存增强Linux内核实时性的技术

多年来,Linux实时性改进技术的发展主要有两种技术方案:(1)直接修改Linux内核。针对内核数据结构、调度函数、中断方式进行改动,重新设计一个由优先级驱动的实时调度器,替换原有Linux内核中的进程调度器sched.c。这一方案主要是针对中断机制、任务调度算法进行改进的,较为成功的案例为Kansas大学开发的Kurt-Linux。Kurt提高了Linux系统中的实时精度,将时钟芯片设置为单触发状态。对于实时任务的调度,Kurt-Linux采用基于时间的静态实时CPU调度算法。实时任务在设计阶段就需要明确地说明其实时事件要发生的时间。这种调度算法对于那些循环执行的任务能够取得较好的调度效果;(2)在Linux内核之外进行实时性扩展,添加一个实时内核。实时内核接管硬件所有中断,并依据是否为实时任务给予响应。Fsm Labs公司开发的RTLinux就是依据这种策略开发设计的 。以上论述的两种技术方案有其可借鉴之处,但如果综合考虑任务响应、内核可抢占性、实时调度策略等都将影响 *** 作系统的实时性能,因此,这两种技术还不能很好地满足实时性要求。为了增强嵌入式Linux实时性能,下面将介绍中断机制、内核的抢占性以及大内核锁等相关问题。

2 Linux实时性改进方法

Linux2.4及以前版本内核是不可抢占的,在Linux2.6中,内核已经可以抢占,实时性有所增强。但是内核中仍然有不可抢占的区域,如自旋锁spinlock保护的临界区等。另外,影响内核实时性能的因素还有中断运行机制、大内核锁机制以及调度算法等。

2.1 中断运行机制改进

在初始化阶段,常规中断初始化和中断线程化的初始化在start_kernel( )函数中都调用trap_init( )和init_IRQ( )两个函数来初始化irq_desc_t结构体,区别主要体现在内核初始化创建init线程时,中断线程化的中断在init( )函数中还将调用init_hardirqs(kernel/irq/manage.c)来为每一个IRQ创建一个内核线程,最高实时优先级为50,依次类推直到25。因此,任何IRQ线程的最低实时优先级为25,具体实现是通过kthread_create函数创建的。功能实现等同于如下代码:

void __init init_hardirqs(void)

{ ……

for (i = 0; i 《 NR_IRQS; i++) {

//对于每一个中断建立一个中断线程

irq_desc_t *desc = irq_desc + i;

if(desc-》acTIon && !(desc-》status & IRQ_NODELAY))

//有IRQ_NODELAY标志的中断不允许线程化

desc-》thread = kthread_create(do_irqd,

desc, “IRQ %d”, irq); //建立线程

……

}

}

staTIc int do_irqd(void * __desc)

//分配中断线程优先级50~25

{ ……

/*Scale irq thread prioriTIes from prio 50 to prio 25 */

param.sched_priority = curr_irq_prio;

if (param.sched_priority 》 25)

curr_irq_prio = param.sched_priority - 1;

……

}

在中断处理阶段当中断发生时,CPU调用do_IRQ( )函数来处理中断,do_IRQ( )在做了必要的相关处理之后调用_do_IRQ( )。_do_IRQ( )主要功能为判断该中断是否已经被线程化(核对终端描述符的状态字段是否包含IRQ_NODELAY标志),对于没有线程化的中断,将直接调用 handle_IRQ_event( )函数来处理。功能实现等同于如下代码:

fastcall notrace unsigned int __do_IRQ(unsigned int irq,

struct pt_regs *regs)

{ ……

if (redirect_hardirq(desc))

//检测是否为线程化中断,若是则唤醒中断线程

goto out_no_end;

……

acTIon_ret = handle_IRQ_event(irq, regs, action);

//处理非线程化中断

……

}

int redirect_hardirq(struct irq_desc *desc)

//检测irq_desc结构体,判断是否线程化

{ ……

if (!hardirq_preemption || (desc-》status & IRQ_

NODELAY) || !desc-》thread)

return 0;

……

if (desc-》thread && desc-》thread-》state != TASK_

RUNNING)

wake_up_process(desc-》thread);

……

}

针对已线程化的情况,调用wake_up_process( )函数唤醒中断处理线程执行,内核线程将调用do_hardirq( )来处理相应的中断。具体实现是通过handle_IRQ_event( )函数直接调用相应的中断处理函数完成的。对于紧急的中断(如时钟中断),内核保持原来的中断处理方式,而不为其创建中断线程,这样就保证了紧急中断的快速响应。

2.2 内核可抢占性设计

在Linux标准内核中,因不具有可抢占性和导致较大的延迟,增加内核的可抢占性能,可提高系统的实时任务处理能力。当前修改Linux内核提高实时性的方法主要有增加抢占点和改造成抢占式内核两种方法。增加抢占点方法是在内核中插入抢占点,通过检测抢占点调度标志来决定是否进行实时任务的调度。采用这种方法,在检测抢占点标志时大大增加了系统开销,因此本方案采用直接改造Linux内核的方法,通过修改自旋锁为互斥锁来提高内核的可抢占性  。即借鉴Ingo Molnar的实时补丁的实时化方法,使用mutex互斥锁来替换spinlock自旋锁。使用mutex替换spinlock,可以让spinlock 可抢占。起初spinlock不可抢占性设计目的是避免死锁,可抢占性设计可能导致竞争者与保持者的死锁局面。中断处理函数中也可以使用 spinlock,如果spinlock已经被某一进程保持,则中断处理函数无法进行,从而形成死锁。中断线程化以后,中断线程将挂在等待队列上并放弃 CPU让别的线程或进程来运行,让每个spinlock都有一个等待队列,该等待队列按进程或线程优先级排队,如果一个进程或线程竞争的spinlock 已经被另一个线程保持,它将把自己挂在该spinlock的优先级化的等待队列上,然后发生调度把CPU让给别的进程或线程。mutex替换 spinlock后,spinlock结构定义如下代码:

typedef struct {

struct rt_mutex lock; //新的实时互斥锁

unsigned int break_lock;

} spinlock_t;

其中struct rt_mutex结构如下:

struct rt_mutex {

raw_spinlock_t wait_lock;

struct plist wait_list; //优先级等待队列

struct task_struct *owner; //拥有该锁进程的信息

int owner_prio;

… …

};

在如上代码中,类型raw_spinlock_t就是原来的spinlock_t。即代码中的spinlock_t就是新设计的自旋锁。rt_mutex 结构中,wait_list字段为优先级等待队列。在mutex使用中,当遇到锁住的临界资源时,任务被挂起到wait_list中,临界资源解锁时等待任务被激活。临界资源被保护的同时可以抢占。

由于Linux内核底层的临界资源是不可抢占的,使用mutex替换spinlock的过程中,这部分可以保留,仍由不可抢占的spinlock保护,如:保护硬件寄存器的锁、调度器的运行队列锁等。不可抢占的spinlock被重新命名为raw_spinlock_t。spin_lock被宏定义为:

#define spin_lock(lock) PICK_OP(raw_spinlock_t,spin,_lock,lock)

函数PICK_OP支持两种锁共存机制,PICK_OP在编译阶段将锁 *** 作转化为mutex或者spinlock:

#define PICK_OP(type, optype, op, lock) \

do { \

if (TYPE_EQUAL((lock), type)) \

_raw_##optype##op((type *)(lock)); \

else if (TYPE_EQUAL(lock, spinlock_t)) \

//调用gcc的内嵌函数__builtin_types_compatible_p()

_spin##op((spinlock_t *)(lock)); \

else __bad_spinlock_type(); \

} while (0)

#define TYPE_EQUAL(lock, type) \

__builtin_types_compatible_p(typeof(lock), type *)

gcc的内嵌函数__builtin_types_compatible_p用于判断一个变量的类型是否为某指定的类型,如果类型为 spinlock_t,将运行函数_spin_lock;类型为raw_spinlock_t,将运行函数_raw_spin_lock。

实时rt_mutex在具体应用中,一个高优先级任务抢占该锁的同时,把先前的锁拥有者添加到互斥锁等待队列中,并在当前拥有该锁的任务 task_struct中标记等待该锁的所有任务;反之,不能得到该锁就把当前任务添加到锁的优先级等待队列中,直到唤醒执行。为了防止优先级逆转,可以改变锁的当前拥有者的优先级为锁的等待队列中任务的最高优先级。

rt_mutex可以使高优先级任务利用抢占锁进入临界区,这样内核不可抢占区的数量和范围大大缩小,内核可抢占性有了很大的提高,且降低了实时高优先级任务的抢占延迟,改善了系统的实时性能。

2.3 可抢占大内核锁设计

大内核锁BKL(Big Kernel Lock)实质上也是spinlock,它用于保护整个内核,该锁保持时间较长,对系统的实时性能影响很大 。采用Ingo Molnar的实时化方法,BKL使用semaphore实现,结构定义如下代码:

struct semaphore {

atomic_t count;

struct rt_mutex lock; //实时互斥锁的使用

};

由结构体发现,在BKL实现中利用了实时互斥锁rt_mutex,在改进后的spinlock结构体spinlock_t中也利用了实时互斥锁 rt_mutex,因此可抢占大内核锁和新的spinlock共用了低层的处理代码。使用semaphore之后,大内核锁就可抢占了。

3 内核实时性测试

针对Linux2.6内核,本文并没有作出对内核调度算法的修正,只是探讨了中断运行机制、自旋锁及大内核锁技术在系统实时性能上的局限性,所以实验测试主要测试中断延迟时间和任务响应时间。实验环境: Intel 2 GHz CPU,256 DDR内存,Kernel 2.6.22版本。测试结果。

由表可知,在中断服务程序中写入标记,测试中断触发至中断服务程序执行平均响应时间,标准Linux2.6内核平均中断响应时间为182 μs,改进后Linux2.6内核为14 μs。采用开源软件LMbench3.0 测试系统任务调度延迟时间,标准Linux2.6内核平均任务响应时间为1 260 μs,改进后Linux2.6内核为162μs。由此可见,改进策略在一定程度上大大减小了中断延迟和任务调度时间,有利于改善移动机器人任务处理的实时性能。

本文基于Linux2.6内核的关中断、中断优先级、内核的不可抢占性以及大内核锁保持时间过长等问题进行了实时性分析,提出了相应的改进方法。利用中断线程化、互斥锁的应用及大内核锁的改进等技术提高了系统的实时性能,降低了内核中断延迟和调度延迟。改进后的内核在移动机器人控制器平台中有很好的应用价值,提高了机器人控制的实时性能。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/dianzi/2716419.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-08-17
下一篇 2022-08-17

发表评论

登录后才能评论

评论列表(0条)

保存