Documentation/translations/zh_CN/core-api/workqueue.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/core-api/workqueue.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/zh_CN/core-api/workqueue.rst- Extension
.rst- Size
- 27970 bytes
- Lines
- 697
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/core-api/workqueue.rst
:翻译:
司延腾 Yanteng Si <siyanteng@loongson.cn>
周彬彬 Binbin Zhou <zhoubinbin@loongson.cn>
陈兴友 Xingyou Chen <rockrush@rockwork.org>
.. _cn_workqueue.rst:
========
工作队列
========
:日期: September, 2010
:作者: Tejun Heo <tj@kernel.org>
:作者: Florian Mickler <florian@mickler.org>
简介
====
在很多情况下,需要一个异步的程序执行环境,工作队列(wq)API是这种情况下
最常用的机制。
当需要这样一个异步执行上下文时,一个描述将要执行的函数的工作项(work,
即一个待执行的任务)被放在队列中。一个独立的线程作为异步执行环境。该队
列被称为workqueue,线程被称为工作者(worker,即执行这一队列的线程)。
当工作队列上有工作项时,工作者会一个接一个地执行与工作项相关的函数。当
工作队列中没有任何工作项时,工作者就会变得空闲。当一个新的工作项被排入
队列时,工作者又开始执行。
为什么要有并发管理工作队列?
===========================
在最初的wq实现中,多线程(MT)wq在每个CPU上有一个工作者线程,而单线程
(ST)wq在全系统有一个工作者线程。一个MT wq需要保持与CPU数量相同的工
作者数量。这些年来,内核增加了很多MT wq的用户,随着CPU核心数量的不断
增加,一些系统刚启动就达到了默认的32k PID的饱和空间。
尽管MT wq浪费了大量的资源,但所提供的并发性水平却不能令人满意。这个限
制在ST和MT wq中都有,只是在MT中没有那么严重。每个wq都保持着自己独立的
工作者池。一个MT wq只能为每个CPU提供一个执行环境,而一个ST wq则为整个
系统提供一个。工作项必须竞争这些非常有限的执行上下文,从而导致各种问题,
包括在单一执行上下文周围容易发生死锁。
(MT wq)所提供的并发性水平和资源使用之间的矛盾也迫使其用户做出不必要的权衡,比
如libata选择使用ST wq来轮询PIO,并接受一个不必要的限制,即没有两个轮
询PIO可以同时进行。由于MT wq并没有提供更好的并发性,需要更高层次的并
发性的用户,如async或fscache,不得不实现他们自己的线程池。
并发管理工作队列(cmwq)是对wq的重新实现,重点是以下目标。
* 保持与原始工作队列API的兼容性。
* 使用由所有wq共享的每CPU统一的工作者池,在不浪费大量资源的情况下按
* 需提供灵活的并发水平。
* 自动调节工作者池和并发水平,使API用户不需要担心这些细节。
设计
====
为了简化函数的异步执行,引入了一个新的抽象概念,即工作项。
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.