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.
255 may queue at the same time.  Unless there is a specific need for
342   there is dependency among multiple work items used during memory
346 * Unless strict ordering is required, there is no need to use ST wq.
348 * Unless there is a specific need, using 0 for @max_active is
356   special attribute, can use one of the system wq.  There is no
443 kernel, there exists a pronounced trade-off between locality and utilization
467 There are 24 issuers, each issuing 64 IOs concurrently. ``--verify=sha512``
494 With enough issuers spread across the system, there is no downside to
509 The only difference from the previous scenario is ``--numjobs=8``. There are
553 reduced to four, there now isn't enough work to saturate the whole system
593 * As there is no one option which is great for most cases, workqueue usages
599   ``WQ_CPU_INTENSIVE`` per-cpu workqueue. There is no real advanage to the
606   originating from the scheduler. There is no theoretical reason why the
724 there are a few tricks needed to shed some light on misbehaving
734 If kworkers are going crazy (using too much cpu), there are two types