论述不同的抢占模型如何影响用户和系统的行为

当配置Linux内核的时候，我们可以选择一些参数，这些参数能影响系统的行为。你可以用不同的优先级、调度类和抢占模型来工作。正确地选择这些参数是非常重要的。

本文将论述不同的抢占模型如何影响用户和系统的行为。

当你使用 make menuconfig配置内核的时候，你能看到这样的菜单：

为了深入理解这三个抢占模型的区别，我们将写一个案例：

2个线程，一个高优先级RT（50），一个低优先级RT（30）

高优先级的线程要睡眠3秒

低优先级的线程用CPU来做计算

3秒后高优先级线程唤醒。

如果低优先级的线程陷入系统调用，高优先级的线程睡眠到期，究竟会发生什么？下面我们来一种模型一种模型地看。

No Forced Preemption

这种情况下，上下文切换发生在系统调用返回用户空间的点。案例如下：

2个线程，一个高优先级RT（50），一个低优先级RT（30）

高优先级的线程要睡眠3秒

低优先级的线程进入系统调用计算5秒

5秒后低优先级线程从内核系统调用返回

高优先级线程将醒来（但是比预期迟了2秒）。

内核代码，简单的字符设备：

#include #include #include #include #include #include #include #include #include #include #include #include static dev_t my_dev;static struct cdev *my_cdev; // callback for read system call on the devicestatic ssize_t my_read(struct file *file, char __user *buf,size_t count,loff_t *ppos){ int len=5; if(*ppos > 0) { return 0; } mdelay(5000); // busy-wait for 5 seconds if (copy_to_user(buf , "hello" , len)) { return -EFAULT; } else { *ppos +=len; return len; }} static struct file_operations my_fops ={ .owner = THIS_MODULE, .read = my_read,}; static int hello_init (void){ my_dev = MKDEV(400,0); register_chrdev_region(my_dev,1,"demo"); my_cdev=cdev_alloc(); if(!my_cdev) { printk (KERN_INFO "cdev alloc error. "); return -1; } my_cdev->ops = &my_fops; my_cdev->owner = THIS_MODULE; if(cdev_add(my_cdev,my_dev,1)) { printk (KERN_INFO "cdev add error. "); return -1; } return 0; } static voidhello_cleanup (void){ cdev_del(my_cdev); unregister_chrdev_region(my_dev, 1);} module_init (hello_init);module_exit (hello_cleanup);MODULE_LICENSE("GPL");

读里面delay了5秒， 注意mdelay是一个计算型的busy-loop。

用户空间代码如下：

#include#include#include#include #include #include void *hi_prio(void *p){ printf("thread1 start time=%ld ",time(NULL)); sleep(3); printf("thread1 stop time=%ld ",time(NULL)); return NULL;} void *low_prio(void *p){ char buf[20]; sleep(1); int fd=open("/dev/demo",O_RDWR); // #mknod /dev/demo c 400 0 puts("thread2 start"); read(fd,buf,20); puts("thread2 stop"); return NULL;} int main(){ pthread_t t1,t2,t3; pthread_attr_t attr; struct sched_param param; pthread_attr_init(&attr); pthread_attr_setschedpolicy(&attr, SCHED_RR); param.sched_priority = 50; pthread_attr_setschedparam(&attr, ¶m); pthread_create(&t1,&attr,hi_prio,NULL); param.sched_priority = 30; pthread_attr_setschedparam(&attr, ¶m); pthread_create(&t2,&attr,low_prio,NULL); sleep(10); puts("end test"); return 0;}

实验步骤：

高优先级线程开始睡眠3秒

低优先级线程睡眠1秒然后做系统调用

高优先级线程6秒后醒来（stop和start的时间差）

# insmod demo.ko # ./appthread1 start time=182thread2 startthread1 stop time=188thread2 stopend test

Preemptible Kernel

这种情况内核里面也可以抢占，意味着上述程序里面的高优先级线程3秒后可醒来。

这种情况下，系统会有更多的上下文切换，但是实时性更加好。对于要求软实时的嵌入式系统而言，这个选项是最佳的。但是对于服务器而言，通常第一个选项更好——更少的上下文切换，更多的CPU时间用作有用功。

运行结果（stop、start时间差3秒）：

# insmod ./demo.ko#./appthread1 start time=234thread2 startthread1 stop time=237thread2 stopend test

Voluntary Kernel Preemption

这种情况和第一种情况"no forced preemption"类似，但是内核开发者可以在进行复杂操作的时候，时不时检查一下是否可以reschedule。他们可以调用might_resched()函数。

在下面的代码中，我们添加了一些检查点（check point）

// callback for read system call on the devicestatic ssize_t my_read(struct file *file, char __user *buf,size_t count,loff_t *ppos){ int len=5; if(*ppos > 0) { return 0; } mdelay(4000); // busy-wait for 4 seconds might_resched(); delay(3000); // busy wait for 3 seconds if (copy_to_user(buf , "hello" , len)) { return -EFAULT; } else { *ppos +=len; return len; }}

如果我们把might_resched()注释掉，它会delay 7秒。

添加cond_resched()调用将导致系统检查是否有高优先级的任务被唤醒，这样高优先级任务5秒可以醒来（其中1秒在systemcall之前，另外4秒在kernel）。

运行结果：

# insmod ./demo.ko#./appthread1 start time=320thread2 startthread1 stop time=325thread2 stopend test

Full Real Time Preemption

如果我们使能RT补丁，我们会得到一个硬实时的kernel。这意味着任何代码可以抢占任何人。比如一个更加紧急的任务可以抢占中断服务程序ISR。这个patch进行了如下改动：

把中断服务程序转化为优先级是50的RT线程

把softIRQ转化为优先级是49的RT线程

把所有的spinlock变成mutex

高精度定时器

其他的细小改动

打补丁后会看到2个新增的菜单：

其中 “Preemptible Kernel (Basic RT)” 是为了调试目的的，为了全面使用RT补丁的功能，我们应该选择最后一项 – Fully Preemptible Kernel。这样我们会有更多的上下文切换，但是可以满足RT的实时要求。