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.
89 There are two worker-pools, one for normal work items and the other
121 stalling should be optimal.  As long as there are one or more runnable
124 schedules a new worker so that the CPU doesn't sit idle while there
136 regulating concurrency level is on the users.  There is also a flag to
156 also used as the name of the rescuer thread if there is one.
236 may queue at the same time.  Unless there is a specific need for
327   there is dependency among multiple work items used during memory
331 * Unless strict ordering is required, there is no need to use ST wq.
333 * Unless there is a specific need, using 0 for @max_active is
341   special attribute, can use one of the system wq.  There is no
423 kernel, there exists a pronounced trade-off between locality and utilization
447 There are 24 issuers, each issuing 64 IOs concurrently. ``--verify=sha512``
474 With enough issuers spread across the system, there is no downside to
489 The only difference from the previous scenario is ``--numjobs=8``. There are
533 reduced to four, there now isn't enough work to saturate the whole system
573 * As there is no one option which is great for most cases, workqueue usages
579   ``WQ_CPU_INTENSIVE`` per-cpu workqueue. There is no real advanage to the
586   originating from the scheduler. There is no theoretical reason why the
704 there are a few tricks needed to shed some light on misbehaving
714 If kworkers are going crazy (using too much cpu), there are two types