Lines Matching +full:0 +full:a
17 When such an asynchronous execution context is needed, a work item
18 describing which function to execute is put on a queue. An
25 When a new work item gets queued, the worker begins executing again.
31 In the original wq implementation, a multi threaded (MT) wq had one
32 worker thread per CPU and a single threaded (ST) wq had one worker
33 thread system-wide. A single MT wq needed to keep around the same
34 number of workers as the number of CPUs. The kernel grew a lot of MT
39 Although MT wq wasted a lot of resource, the level of concurrency
55 Concurrency Managed Workqueue (cmwq) is a reimplementation of wq with
61 flexible level of concurrency on demand without wasting a lot of
71 In order to ease the asynchronous execution of functions a new
74 A work item is a simple struct that holds a pointer to the function
75 that is to be executed asynchronously. Whenever a driver or subsystem
76 wants a function to be executed asynchronously it has to set up a work
77 item pointing to that function and queue that work item on a
80 A work item can be executed in either a thread or the BH (softirq) context.
99 the BH execution context. A BH workqueue can be considered a convenience
107 get a detailed overview refer to the API description of
110 When a work item is queued to a workqueue, the target worker-pool is
113 unless specifically overridden, a work item of a bound workqueue will
119 tries to keep the concurrency at a minimal but sufficient level.
127 not expected to hog a CPU and consume many cycles. That means
130 workers on the CPU, the worker-pool doesn't start execution of a new
132 schedules a new worker so that the CPU doesn't sit idle while there
133 are pending work items. This allows using a minimal number of workers
137 for kthreads, so cmwq holds onto idle ones for a while before killing
144 regulating concurrency level is on the users. There is also a flag to
145 mark a bound wq to ignore the concurrency management. Please refer to
152 wq's that have a rescue-worker reserved for execution under memory
160 ``alloc_workqueue()`` allocates a wq. The original
166 A wq no longer manages execution resources but serves as a domain for
176 BH workqueues can be considered a convenience interface to softirq. BH
180 All BH workqueues must have 0 ``max_active`` and ``WQ_HIGHPRI`` is the
189 specific CPU. This makes the wq behave as a simple execution
204 A freezable wq participates in the freeze phase of the system
214 Work items of a highpri wq are queued to the highpri
223 Work items of a CPU intensive wq do not contribute to the
243 CPU which can be assigned to the work items of a wq. For example, with
245 at the same time per CPU. This is always a per-CPU attribute, even for
249 when 0 is specified is 256. These values are chosen sufficiently high
253 The number of active work items of a wq is usually regulated by the
255 may queue at the same time. Unless there is a specific need for
256 throttling the number of active work items, specifying '0' is
272 Work items w0, w1, w2 are queued to a bound wq q0 on the same CPU.
282 0 w0 starts and burns CPU
296 0 w0 starts and burns CPU
310 0 w0 starts and burns CPU
321 Now, let's assume w1 and w2 are queued to a different wq q1 which has
325 0 w0 starts and burns CPU
339 * Do not forget to use ``WQ_MEM_RECLAIM`` if a wq may process work
348 * Unless there is a specific need, using 0 for @max_active is
352 * A wq serves as a domain for forward progress guarantee
355 flushed as a part of a group of work items, and don't require any
357 difference in execution characteristics between using a dedicated wq
358 and a system wq.
360 * Unless work items are expected to consume a huge amount of CPU
361 cycles, using a bound wq is usually beneficial due to the increased
369 cache locality. For example, if a workqueue is using the default affinity
371 boundaries. A work item queued on the workqueue will be assigned to a worker
383 CPUs are not grouped. A work item issued on one CPU is processed by a
393 boundary is used is determined by the arch code. L3 is used in a lot of
400 All CPUs are put in the same group. Workqueue makes no effort to process a
401 work item on a CPU close to the issuing CPU.
404 ``workqueue.default_affinity_scope`` and a specific workqueue's affinity
418 0 by default indicating that affinity scopes are not strict. When a work
419 item starts execution, workqueue makes a best-effort attempt to ensure
438 kernel, there exists a pronounced trade-off between locality and utilization
447 The tests are run on a CPU with 12-cores/24-threads split across four L3
449 ``/dev/dm-0`` is a dm-crypt device created on NVME SSD (Samsung 990 PRO) and
458 $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k --ioengine=libaio \
500 $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
505 a third of the issuers but is still enough total work to saturate the
543 $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
583 While the loss of work-conservation in certain scenarios hurts, it is a lot
589 that may consume a significant amount of CPU are recommended to configure
595 latter and an unbound workqueue provides a lot more flexibility.
620 pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
621 pod_node [0]=0 [1]=0 [2]=1 [3]=1
622 cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
626 pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
627 pod_node [0]=0 [1]=0 [2]=1 [3]=1
628 cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
632 pod_cpus [0]=00000003 [1]=0000000c
633 pod_node [0]=0 [1]=1
634 cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
638 pod_cpus [0]=00000003 [1]=0000000c
639 pod_node [0]=0 [1]=1
640 cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
644 pod_cpus [0]=0000000f
645 pod_node [0]=-1
646 cpu_pod [0]=0 [1]=0 [2]=0 [3]=0
650 pool[00] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 0
651 pool[01] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 0
652 pool[02] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 1
654 pool[04] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 2
656 pool[06] ref= 1 nice= 0 idle/workers= 3/ 3 cpu= 3
658 pool[08] ref=42 nice= 0 idle/workers= 6/ 6 cpus=0000000f
659 pool[09] ref=28 nice= 0 idle/workers= 3/ 3 cpus=00000003
660 pool[10] ref=28 nice= 0 idle/workers= 17/ 17 cpus=0000000c
667 [ workqueue \ CPU 0 1 2 3 dfl]
668 events percpu 0 2 4 6
670 events_long percpu 0 2 4 6
672 events_freezable percpu 0 2 4 6
673 events_power_efficient percpu 0 2 4 6
674 events_freezable_pwr_ef percpu 0 2 4 6
675 rcu_gp percpu 0 2 4 6
676 rcu_par_gp percpu 0 2 4 6
677 slub_flushwq percpu 0 2 4 6
691 events 18545 0 6.1 0 5 - -
692 events_highpri 8 0 0.0 0 0 - -
693 events_long 3 0 0.0 0 0 - -
694 events_unbound 38306 0 0.1 - 7 - -
695 events_freezable 0 0 0.0 0 0 - -
696 events_power_efficient 29598 0 0.2 0 0 - -
697 events_freezable_pwr_ef 10 0 0.0 0 0 - -
698 sock_diag_events 0 0 0.0 0 0 - -
701 events 18548 0 6.1 0 5 - -
702 events_highpri 8 0 0.0 0 0 - -
703 events_long 3 0 0.0 0 0 - -
704 events_unbound 38322 0 0.1 - 7 - -
705 events_freezable 0 0 0.0 0 0 - -
706 events_power_efficient 29603 0 0.2 0 0 - -
707 events_freezable_pwr_ef 10 0 0.0 0 0 - -
708 sock_diag_events 0 0 0.0 0 0 - -
719 there are a few tricks needed to shed some light on misbehaving
724 root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1]
725 root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2]
726 root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0]
727 root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0]
733 2. A single work item that consumes lots of cpu cycles
739 (wait a few secs)
758 Workqueue guarantees that a work item cannot be re-entrant if the following
759 conditions hold after a work item gets queued:
770 required when breaking the conditions inside a work function.