背景
Read the fucking source code!
--By 鲁迅A picture is worth a thousand words.
--By 高尔基
说明:
- Kernel版本:4.14
- ARM64处理器,Contex-A53,双核
- 使用工具:Source Insight 3.5, Visio
1. 概述
Workqueue
工作队列是利用内核线程来异步执行工作任务的通用机制;Workqueue
工作队列可以用作中断处理的Bottom-half
机制,利用进程上下文来执行中断处理中耗时的任务,因此它允许睡眠,而Softirq
和Tasklet
在处理任务时不能睡眠;
来一张概述图:
- 在中断处理过程中,或者其他子系统中,调用
workqueue
的调度或入队接口后,通过建立好的链接关系图逐级找到合适的worker
,最终完成工作任务的执行;
2. 数据结构
2.1 总览
此处应有图:
- 先看看关键的数据结构:
work_struct
:工作队列调度的最小单位,work item
;workqueue_struct
:工作队列,work item
都挂入到工作队列中;worker
:work item
的处理者,每个worker
对应一个内核线程;worker_pool
:worker
池(内核线程池),是一个共享资源池,提供不同的worker
来对work item
进行处理;pool_workqueue
:充当桥梁纽带的作用,用于连接workqueue
和worker_pool
,建立链接关系;
下边看看细节吧:
2.2 work
struct work_struct
用来描述work
,初始化一个work
并添加到工作队列后,将会将其传递到合适的内核线程来进行处理,它是用于调度的最小单位。
关键字段描述如下:
struct work_struct {
atomic_long_t data; //低比特存放状态位,高比特存放worker_pool的ID或者pool_workqueue的指针
struct list_head entry; //用于添加到其他队列上
work_func_t func; //工作任务的处理函数,在内核线程中回调
#ifdef CONFIG_LOCKDEP
struct lockdep_map lockdep_map;
#endif
};
图片说明下data
字段:
2.3 workqueue
-
内核中工作队列分为两种:
- bound:绑定处理器的工作队列,每个
worker
创建的内核线程绑定到特定的CPU上运行; - unbound:不绑定处理器的工作队列,创建的时候需要指定
WQ_UNBOUND
标志,内核线程可以在处理器间迁移;
- bound:绑定处理器的工作队列,每个
-
内核默认创建了一些工作队列(用户也可以创建):
system_mq
:如果work item
执行时间较短,使用本队列,调用schedule[_delayed]_work[_on]()
接口就是添加到本队列中;system_highpri_mq
:高优先级工作队列,以nice值-20来运行;system_long_wq
:如果work item
执行时间较长,使用本队列;system_unbound_wq
:该工作队列的内核线程不绑定到特定的处理器上;system_freezable_wq
:该工作队列用于在Suspend时可冻结的work item
;system_power_efficient_wq
:该工作队列用于节能目的而选择牺牲性能的work item
;system_freezable_power_efficient_wq
:该工作队列用于节能或Suspend时可冻结目的的work item
;
struct workqueue_struct
关键字段介绍如下:
struct workqueue_struct {
struct list_head pwqs; /* WR: all pwqs of this wq */ //所有的pool_workqueue都添加到本链表中
struct list_head list; /* PR: list of all workqueues */ //用于将工作队列添加到全局链表workqueues中
struct list_head maydays; /* MD: pwqs requesting rescue */ //rescue状态下的pool_workqueue添加到本链表中
struct worker *rescuer; /* I: rescue worker */ //rescuer内核线程,用于处理内存紧张时创建工作线程失败的情况
struct pool_workqueue *dfl_pwq; /* PW: only for unbound wqs */
char name[WQ_NAME_LEN]; /* I: workqueue name */
/* hot fields used during command issue, aligned to cacheline */
unsigned int flags ____cacheline_aligned; /* WQ: WQ_* flags */
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */ //Per-CPU都创建pool_workqueue
struct pool_workqueue __rcu *numa_pwq_tbl[]; /* PWR: unbound pwqs indexed by node */ //Per-Node创建pool_workqueue
...
};
2.4 worker
- 每个
worker
对应一个内核线程,用于对work item
的处理; worker
根据工作状态,可以添加到worker_pool
的空闲链表或忙碌列表中;worker
处于空闲状态时并接收到工作处理请求,将唤醒内核线程来处理;- 内核线程是在每个
worker_pool
中由一个初始的空闲工作线程创建的,并根据需要动态创建和销毁;
关键字段描述如下:
struct worker {
/* on idle list while idle, on busy hash table while busy */
union {
struct list_head entry; /* L: while idle */ //用于添加到worker_pool的空闲链表中
struct hlist_node hentry; /* L: while busy */ //用于添加到worker_pool的忙碌列表中
};
struct work_struct *current_work; /* L: work being processed */ //当前正在处理的work
work_func_t current_func; /* L: current_work's fn */ //当前正在执行的work回调函数
struct pool_workqueue *current_pwq; /* L: current_work's pwq */ //指向当前work所属的pool_workqueue
struct list_head scheduled; /* L: scheduled works */ //所有被调度执行的work都将添加到该链表中
/* 64 bytes boundary on 64bit, 32 on 32bit */
struct task_struct *task; /* I: worker task */ //指向内核线程
struct worker_pool *pool; /* I: the associated pool */ //该worker所属的worker_pool
/* L: for rescuers */
struct list_head node; /* A: anchored at pool->workers */ //添加到worker_pool->workers链表中
/* A: runs through worker->node */
...
};
2.5 worker_pool
worker_pool
是一个资源池,管理多个worker
,也就是管理多个内核线程;- 针对绑定类型的工作队列,
worker_pool
是Per-CPU创建,每个CPU都有两个worker_pool
,对应不同的优先级,nice值分别为0和-20; - 针对非绑定类型的工作队列,
worker_pool
创建后会添加到unbound_pool_hash
哈希表中; worker_pool
管理一个空闲链表和一个忙碌列表,其中忙碌列表由哈希管理;
关键字段描述如下:
struct worker_pool {
spinlock_t lock; /* the pool lock */
int cpu; /* I: the associated cpu */ //绑定到CPU的workqueue,代表CPU ID
int node; /* I: the associated node ID */ //非绑定类型的workqueue,代表内存Node ID
int id; /* I: pool ID */
unsigned int flags; /* X: flags */
unsigned long watchdog_ts; /* L: watchdog timestamp */
struct list_head worklist; /* L: list of pending works */ //pending状态的work添加到本链表
int nr_workers; /* L: total number of workers */ //worker的数量
/* nr_idle includes the ones off idle_list for rebinding */
int nr_idle; /* L: currently idle ones */
struct list_head idle_list; /* X: list of idle workers */ //处于IDLE状态的worker添加到本链表
struct timer_list idle_timer; /* L: worker idle timeout */
struct timer_list mayday_timer; /* L: SOS timer for workers */
/* a workers is either on busy_hash or idle_list, or the manager */
DECLARE_HASHTABLE(busy_hash, BUSY_WORKER_HASH_ORDER); //工作状态的worker添加到本哈希表中
/* L: hash of busy workers */
/* see manage_workers() for details on the two manager mutexes */
struct worker *manager; /* L: purely informational */
struct mutex attach_mutex; /* attach/detach exclusion */
struct list_head workers; /* A: attached workers */ //worker_pool管理的worker添加到本链表中
struct completion *detach_completion; /* all workers detached */
struct ida worker_ida; /* worker IDs for task name */
struct workqueue_attrs *attrs; /* I: worker attributes */
struct hlist_node hash_node; /* PL: unbound_pool_hash node */ //用于添加到unbound_pool_hash中
...
} ____cacheline_aligned_in_smp;
2.6 pool_workqueue
pool_workqueue
充当纽带的作用,用于将workqueue
和worker_pool
关联起来;
关键字段描述如下:
struct pool_workqueue {
struct worker_pool *pool; /* I: the associated pool */ //指向worker_pool
struct workqueue_struct *wq; /* I: the owning workqueue */ //指向所属的workqueue
int nr_active; /* L: nr of active works */ //活跃的work数量
int max_active; /* L: max active works */ //活跃的最大work数量
struct list_head delayed_works; /* L: delayed works */ //延迟执行的work挂入本链表
struct list_head pwqs_node; /* WR: node on wq->pwqs */ //用于添加到workqueue链表中
struct list_head mayday_node; /* MD: node on wq->maydays */ //用于添加到workqueue链表中
...
} __aligned(1 << WORK_STRUCT_FLAG_BITS);
2.7 小结
再来张图,首尾呼应一下:
3. 流程分析
3.1 workqueue子系统初始化
workqueue
子系统的初始化分成两步来完成的:workqueue_init_early
和workqueue_init
。
3.1.1 workqueue_init_early
workqueue
子系统早期初始化函数完成的主要工作包括:- 创建
pool_workqueue
的SLAB缓存,用于动态分配struct pool_workqueue
结构; - 为每个CPU都分配两个
worker_pool
,其中的nice值分别为0和HIGHPRI_NICE_LEVEL
,并且为每个worker_pool
从worker_pool_idr
中分配一个ID号; - 为unbound工作队列创建默认属性,
struct workqueue_attrs
属性,主要描述内核线程的nice值,以及cpumask值,分别针对优先级以及允许在哪些CPU上执行; - 为系统默认创建几个工作队列,这几个工作队列的描述在上文的数据结构部分提及过,不再赘述;
- 创建
从图中可以看出创建工作队列的接口为:alloc_workqueue
,如下图:
alloc_workqueue
完成的主要工作包括:- 首先当然是要分配一个
struct workqueue_struct
的数据结构,并且对该结构中的字段进行初始化操作; - 前文提到过
workqueue
最终需要和worker_pool
关联起来,而这个纽带就是pool_workqueue
,alloc_and_link_pwqs
函数就是完成这个功能:1)如果工作队列是绑定到CPU上的,则为每个CPU都分配pool_workqueue
并且初始化,通过link_pwq
将工作队列与pool_workqueue
建立连接;2)如果工作队列不绑定到CPU上,则按内存节点(NUMA,参考之前内存管理的文章)来分配pool_workqueue
,调用get_unbound_pool
来实现,它会根据wq属性先去查找,如果没有找到相同的就创建一个新的pool_workqueue
,并且添加到unbound_pool_hash
哈希表中,最后也会调用link_pwq
来建立连接; - 创建工作队列时,如果设置了
WQ_MEM_RECLAIM
标志,则会新建rescuer worker
,对应rescuer_thread
内核线程。当内存紧张时,新创建worker
可能会失败,这时候由rescuer
来处理这种情况; - 最终将新建好的工作队列添加到全局链表
workqueues
中;
- 首先当然是要分配一个
3.1.2 workqueue_init
workqueue
子系统第二阶段的初始化:
- 主要完成的工作是给之前创建好的
worker_pool
,添加一个初始的worker
; create_worker
函数中,创建的内核线程名字为kworker/XX:YY
或者kworker/uXX:YY
,其中XX
表示worker_pool
的编号,YY
表示worker
的编号,u
表示unbound
;
workqueue
子系统初始化完成后,基本就已经将数据结构的关联建立好了,当有work
来进行调度的时候,就可以进行处理了。
3.2 work调度
3.2.1 schedule_work
以schedule_work
接口为例进行分析:
-
schedule_work
默认是将work
添加到系统的system_work
工作队列中; -
queue_work_on
接口中的操作判断要添加work
的标志位,如果已经置位了WORK_STRUCT_PENDING_BIT
,表明已经添加到了队列中等待执行了,否则,需要调用__queue_work
来进行添加。注意了,这个操作是在关中断的情况下进行的,因为工作队列使用WORK_STRUCT_PENDING_BIT
位来同步work
的插入和删除操作,设置了这个比特后,然后才能执行work
,这个过程可能被中断或抢占打断; -
workqueue
的标志位设置了__WQ_DRAINING
,表明工作队列正在销毁,所有的work
都要处理完,此时不允许再将work
添加到队列中,有一种特殊情况:销毁过程中,执行work
时又触发了新的work
,也就是所谓的chained work
; -
判断
workqueue
的类型,如果是bound
类型,根据CPU来获取pool_workqueue
,如果是unbound
类型,通过node号来获取pool_workqueue
; -
get_work_pool
获取上一次执行work
的worker_pool
,如果本次执行的worker_pool
与上次执行的worker_pool
不一致,且通过find_worker_executing_work
判断work
正在某个worker_pool
中的worker
中执行,考虑到缓存热度,放到该worker
执行是更合理的选择,进而根据该worker
获取到pool_workqueue
; -
判断
pool_workqueue
活跃的work
数量,少于最大限值则将work
加入到pool->worklist
中,否则加入到pwq->delayed_works
链表中,如果__need_more_worker
判断没有worker
在执行,则唤醒worker
内核线程执行; -
总结:
schedule_work
完成的工作是将work
添加到对应的链表中,而在添加的过程中,首先是需要确定pool_workqueue
;pool_workqueue
对应一个worker_pool
,因此确定了pool_workqueue
也就确定了worker_pool
,进而可以将work
添加到工作链表中;pool_workqueue
的确定分为三种情况:1)bound
类型的工作队列,直接根据CPU号获取;2)unbound
类型的工作队列,根据node号获取,针对unbound
类型工作队列,pool_workqueue
的释放是异步执行的,需要判断refcnt
的计数值,因此在获取pool_workqueue
时可能要多次retry
;3)根据缓存热度,优先选择正在被执行的worker_pool
;
3.2.2 worker_thread
work
添加到工作队列后,最终的执行在worker_thread
函数中:
-
在创建
worker
时,创建内核线程,执行函数为worker_thread
; -
worker_thread
在开始执行时,设置标志位PF_WQ_WORKER
,调度器在进行调度处理时会对task进行判断,针对workerqueue worker
有特殊处理; -
worker
对应的内核线程,在没有处理work
的时候是睡眠状态,当被唤醒的时候,跳转到woke_up
开始执行; -
woke_up
之后,如果此时worker
是需要销毁的,那就进行清理工作并返回。否则,离开IDLE
状态,并进入recheck
模块执行; -
recheck
部分,首先判断是否需要更多的worker
来处理,如果没有任务处理,跳转到sleep
地方进行睡眠。有任务需要处理时,会判断是否有空闲内核线程以及是否需要动态创建,再清除掉worker
的标志位,然后遍历工作链表,对链表中的每个节点调用process_one_worker
来处理; -
sleep
部分比较好理解,没有任务处理时,worker
进入空闲状态,并将当前的内核线程设置成睡眠状态,让出CPU; -
总结:
- 管理
worker_pool
的内核线程池时,如果有PENDING
状态的work
,并且发现没有正在运行的工作线程(worker_pool->nr_running == 0
),唤醒空闲状态的内核线程,或者动态创建内核线程; - 如果
work
已经在同一个worker_pool
的其他worker
中执行,不再对该work
进行处理;
- 管理
work
的执行函数为process_one_worker
:
work
可能在同一个CPU上不同的worker
中运行,直接退出;- 调用
worker->current_func()
,完成最终work
的回调函数执行;
3.3 worker动态管理
3.3.1 worker状态机变换
worker_pool
通过nr_running
字段来在不同的状态机之间进行切换;worker_pool
中有work
需要处理时,需要至少保证有一个运行状态的worker
,当nr_running
大于1时,将多余的worker
进入IDLE状态,没有work
需要处理时,所有的worker
都会进入IDLE状态;- 执行
work
时,如果回调函数阻塞运行,那么会让worker
进入睡眠状态,此时调度器会进行判断是否需要唤醒另一个worker
; - IDLE状态的
worker
都存放在idle_list
链表中,如果空闲时间超过了300秒,则会将其进行销毁;
- 当
worker
进入睡眠状态时,如果该worker_pool
没有其他的worker
处于运行状态,那么是需要唤醒一个空闲的worker
来维持并发处理的能力;
- 睡眠状态可以通过
wake_up_worker
来进行唤醒处理,最终判断如果该worker
不在运行状态,则增加worker_pool
的nr_running
值;
3.3.2 worker的动态添加和删除
worker_pool
初始化时,注册了timer的回调函数,用于定时对空闲链表上的worker
进行处理,如果worker
太多,且空闲时间太长,超过了5分钟,那么就直接进行销毁处理了;
- 内核线程执行
worker_thread
函数时,如果没有空闲的worker
,会调用manage_workers
接口来创建更多的worker
来处理工作;
参考
Documentation/core-api/workqueue.rst
http://kernel.meizu.com/linux-workqueue.html
洗洗睡了,收工!