
1)rq: 进程的运行队列( runqueue), 每个CPU对应一个 ,包含自旋锁(spinlock)、进程数量、用于公平调度的CFS信息结构、当前运行的进程描述符等。实际的进程队列用红黑树来维护(通过CFS信息结构来访问)。
2)cfs_rq: cfs调度的进程运行队列信息 ,包含红黑树的根结点、正在运行的进程指针、用于负载均衡的叶子队列等。
3)sched_entity: 把需要调度的东西抽象成调度实体 ,调度实体可以是进程、进程组、用户等。这里包含负载权重值、对应红黑树结点、 虚拟运行时vruntime 等。
4)sched_class:把 调度策略(算法)抽象成调度类 ,包含一组通用的调度 *** 作接口。接口和实现是分离,可以根据调度接口去实现不同的调度算法,使一个Linux调度程序可以有多个不同的调度策略。
1) 关闭内核抢占 ,初始化部分变量。获取当前CPU的ID号,并赋值给局部变量CPU, 使rq指向CPU对应的运行队列 。 标识当前CPU发生任务切换 ,通知RCU更新状态,如果当前CPU处于rcu_read_lock状态,当前进程将会放入rnp->blkd_tasks阻塞队列,并呈现在rnp->gp_tasks链表中。 关闭本地中断 ,获取所要保护的运行队列的自旋锁, 为查找可运行进程做准备 。
2) 检查prev的状态,更新运行队列 。如果不是可运行状态,而且在内核态没被抢占,应该从运行队列中 删除prev进程 。如果是非阻塞挂起信号,而且状态为TASK_INTER-RUPTIBLE,就把该进程的状态设置为TASK_RUNNING,并将它 插入到运行队列 。
3)task_on_rq_queued(prev) 将pre进程插入到运行队列的队尾。
4)pick_next_task 选取将要执行的next进程。
5)context_switch(rq, prev, next)进行 进程上下文切换 。
1) 该进程分配的CPU时间片用完。
2) 该进程主动放弃CPU(例如IO *** 作)。
3) 某一进程抢占CPU获得执行机会。
Linux并没有使用x86 CPU自带的任务切换机制,需要通过手工的方式实现了切换。
进程创建后在内核的数据结构为task_struct , 该结构中有掩码属性cpus_allowed,4个核的CPU可以有4位掩码,如果CPU开启超线程,有一个8位掩码,进程可以运行在掩码位设置为1的CPU上。
Linux内核API提供了两个系统调用 ,让用户可以修改和查看当前的掩码:
1) sched_setaffinity():用来修改位掩码。
2) sched_getaffinity():用来查看当前的位掩码。
在下次task被唤醒时,select_task_rq_fair根据cpu_allowed里的掩码来确定将其置于哪个CPU的运行队列,一个进程在某一时刻只能存在于一个CPU的运行队列里。
在Nginx中,使用了CPU亲和度来完成某些场景的工作:
worker_processes 4
worker_cpu_affinity 0001001001001000
上面这个配置说明了4个工作进程中的每一个和一个CPU核挂钩。如果这个内容写入Nginx的配置文件中,然后Nginx启动或者重新加载配置的时候,若worker_process是4,就会启用4个worker,然后把worker_cpu_affinity后面的4个值当作4个cpu affinity mask,分别调用ngx_setaffinity,然后就把4个worker进程分别绑定到CPU0~3上。
worker_processes 2
worker_cpu_affinity 01011010
上面这个配置则说明了两个工作进程中的每一个和2个核挂钩。
创建一个per-CPU *编译期间静态创建一个per-CPU DEFINE_PER_CPU(type, name) 创建一个名为name,数据类型为type的per-CPU,比如static DEFINE_PER_CPU(struct sk_buff_head, bs_cpu_queues),此时每个CPU都有一个名叫bs_cpu_queues,数据结构为sk_buff_head的变量副本。每个副本都是在自己的CPU上工作。 * 动态创建per-CPU,以下代码是内核create_workqueue实现的片断 struct workqueue_struct *__create_workqueue(const char *name, int singlethread) { int cpu, destroy = 0struct workqueue_struct *wqstruct task_struct *pwq = kzalloc(sizeof(*wq), GFP_KERNEL)if (!wq) return NULLwq->cpu_wq = alloc_percpu(struct cpu_workqueue_struct)if (!wq->cpu_wq) { kfree(wq)return NULL} …… }创建一个名为name,数据类型为type的per-CPU,比如static DEFINE_PER_CPU(struct sk_buff_head, bs_cpu_queues),此时每个CPU都有一个名叫bs_cpu_queues,数据结构为sk_buff_head的变量副本。每个副本都是在自己的CPU上工作。Linux 2.6内核使用了不少工作队列来处理任务,他在使用上和 tasklet最大的不同是工作队列的函数可以使用休眠,而tasklet的函数是不允许使用休眠的。工作队列的使用又分两种情况,一种是利用系统共享的工作队列来添加自己的工作,这种情况处理函数不能消耗太多时间,这样会影响共享队列中其他任务的处理另外一种是创建自己的工作队列并添加工作。第二步:创建一个工作结构体变量,并将处理函数和参数的入口地址赋给这个工作结构体变量如果不想要在编译时就用DECLARE_WORK()创建并初始化工作结构体变量,也可以在程序运行时再用INIT_WORK()创建struct work_struct my_work//创建一个名为my_work的结构体变量,创建后才能使用INIT_WORK()INIT_WORK(&my_work,my_func,&data)//初始化已经创建的my_work,其实就是往这个结构体变量中添加处理函数的入口地址和data的地址,通常在驱动的open函数中完成INIT_WORK(&my_work, my_func, &data)//创建一个工作结构体变量并初始化,和第一种情况的方法一样//作用与schedule_work()类似,不同的是将工作添加入p_queue指针指向的工作队列而不是系统共享的工作队列work queue是一种bottom half,中断处理的后半程,强调的是动态的概念,即work是重点,而queue是其次。wait queue是一种「任务队列」,可以把一些进程放在上面睡眠等待某个事件,强调静态多一些,重点在queue上,即它就是一个queue,这个queue如何调度,什么时候调度并不重要等待队列在内核中有很多用途,尤其适合用于中断处理,进程同步及定时。这里只说,进程经常必须等待某些事件的发生。例如,等待一个磁盘 *** 作的终止,等待释放系统资源,或者等待时间经过固定的间隔。等待队列实现了在事件上的条件等待,希望等待特定事件的进程把放进合适的等待队列,并放弃控制权。因此。等待队列表示一组睡眠的进程,当某一条件为真时,由内核唤醒进程。等待队列由循环链表实现,其元素包括指向进程描述符的指针。每个等待队列都有一个等待队列头,等待队列头是一个类型为wait_queue_head_t的数据结构。等待队列链表的每个元素代表一个睡眠进程,该进程等待某一事件的发生,描述符地址存放在task字段中。然而,要唤醒等待队列中所有的进程有时并不方便。例如,如果两个或多个进程在等待互斥访问某一个要释放的资源,仅唤醒等待队列中一个才有意义。这个进程占有资源,而其他进程继续睡眠可以用DECLARE_WAIT_QUEUE_HEAD(name)宏定义一个新的等待队列,该宏静态地声明和初始化名为name的等待队列头变量。 init_waitqueue_head()函数用于初始化已动态分配的wait queue head变量等待队列可以通过DECLARE_WAITQUEUE()静态创建,也可以用init_waitqueue_head()动态创建。进程放入等待队列并设置成不可执行状态。工作队列,workqueue,它允许内核代码来请求在将来某个时间调用一个函数。用来处理不是很紧急事件的回调方式处理方法.工作队列的作用就是把工作推后,交由一个内核线程去执行,更直接的说就是写了一个函数,而现在不想马上执行它,需要在将来某个时刻去执行,那就得用工作队列准没错。如果需要用一个可以重新调度的实体来执行下半部处理,也应该使用工作队列。是唯一能在进程上下文运行的下半部实现的机制。这意味着在需要获得大量的内存时、在需要获取信号量时,在需要执行阻塞式的I/O *** 作时,都会非常有用。欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)