Lines Matching full:there

13 There are many cases where an asynchronous process execution context
22 While there are work items on the workqueue the worker executes the
24 there is no work item left on the workqueue the worker becomes idle.
91 There are two worker-pools, one for normal work items and the other
96 BH workqueues use the same framework. However, as there can only be one
97 concurrent execution context, there's no need to worry about concurrency.
129 stalling should be optimal.  As long as there are one or more runnable
132 schedules a new worker so that the CPU doesn't sit idle while there
144 regulating concurrency level is on the users.  There is also a flag to
164 also used as the name of the rescuer thread if there is one.
261 may queue at the same time.  Unless there is a specific need for
348   there is dependency among multiple work items used during memory
352 * Unless strict ordering is required, there is no need to use ST wq.
354 * Unless there is a specific need, using 0 for @max_active is
362   special attribute, can use one of the system wq.  There is no
449 kernel, there exists a pronounced trade-off between locality and utilization
473 There are 24 issuers, each issuing 64 IOs concurrently. ``--verify=sha512``
500 With enough issuers spread across the system, there is no downside to
515 The only difference from the previous scenario is ``--numjobs=8``. There are
559 reduced to four, there now isn't enough work to saturate the whole system
599 * As there is no one option which is great for most cases, workqueue usages
605   ``WQ_CPU_INTENSIVE`` per-cpu workqueue. There is no real advanage to the
612   originating from the scheduler. There is no theoretical reason why the
730 there are a few tricks needed to shed some light on misbehaving
740 If kworkers are going crazy (using too much cpu), there are two types