Searched full:waiting (Results 1 – 25 of 189) sorted by relevance
12345678
| /Documentation/ABI/testing/ |
| D | sysfs-devices-waiting_for_supplier | 10 or 1) reflects whether the device is waiting for one or more
14 A value of 0 means the device is not waiting for any suppliers
16 is waiting for one or more suppliers to be added before it can
|
| D | sysfs-class-scsi_tape | 16 Shows the total amount of time spent waiting for all I/O
23 To determine the amount of time spent waiting for other I/O
64 Shows the total amount of time in nanoseconds waiting for
95 Shows the total amount of time in nanoseconds waiting for
|
| D | sysfs-bus-iio-distance-srf08 | 8 This setting limits the time the driver is waiting for a
|
| D | sysfs-fs-incfs | 47 result of waiting for a pending read.
53 result of waiting for a pending read.
|
| D | sysfs-class-vduse | 31 (RW) The timeout (in seconds) for waiting for the control
|
| D | sysfs-block-aoe | 29 commands waiting for a response. It will retry again after being
|
| D | sysfs-tty | 101 Waiting forever is represented as 0. If waiting on close is
|
| /Documentation/scheduler/ |
| D | completion.rst | 22 until the result is actually needed, and both the waiting and the signalling
26 the Linux scheduler. The event the threads on the waitqueue are waiting for
39 - the waiting part through a call to one of the variants of wait_for_completion(),
43 Note that while initialization must happen first, the waiting and signaling
57 This provides the ->wait waitqueue to place tasks on for waiting (if any), and
122 must not return to a calling context until all activities (such as waiting
125 To emphasise this again: in particular when using some of the waiting API variants
141 Waiting for completions:
164 to wait_for_completion() then the waiting side simply will continue
181 time depending on the nature of the activity they are waiting for, so in
[all …]
|
| /Documentation/filesystems/ |
| D | incfs.rst | 61 waiting for a pending read.
65 waiting for a pending read.
80 waiting is split between reads_delayed_pending_us, which is increased by the
81 time spent waiting for the pending read, and reads_delayed_min_us, which is
82 increased by the remainder of the time spent waiting.
|
| D | orangefs.rst | 327 * waiting
330 - op is in progress (waiting for downcall)
337 - submitter has given up waiting for it
345 Service_operation changes the op's state to "waiting", puts
356 the op's state is set to "waiting" and the op is added back to
367 The file_operations.write_iter function returns to the waiting vfs,
383 trying to use Orangefs will be negatively affected. Waiting ops
|
| /Documentation/locking/ |
| D | robust-futex-ABI.rst | 24 call, and handles contested locking by maintaining a list of waiting
26 waiting on a particular futex, and waking up the next waiter on a
34 waiting on the same locks.
82 waiting for a lock on a threads exit if that next thread used the futex
90 indicating their holder died, and wakeup the next thread waiting for
168 they were waiting, and bit 30 is set by the kernel to indicate that the
|
| D | futex-requeue-pi.rst | 17 pthread_cond_broadcast() must resort to waking all the tasks waiting
90 is necessary for both the requeue code, as well as the waiting code,
113 possibly wake the waiting tasks. Internally, this system call is
|
| D | lockdep-design.rst | 150 could lead to the two contexts waiting for each other permanently. The
480 is not a deadlock for recursive read locks, as while the task B is waiting for
509 Task A is waiting for task B to read_unlock() Y and task B is waiting for task
634 waiting scenario and nobody can get progress, therefore a deadlock.
642 waiting scenario, means there are N CPU/tasks, where CPU/task P1 is waiting for
643 a lock held by P2, and P2 is waiting for a lock held by P3, ... and Pn is waiting
644 for a lock held by P1. Let's name the lock Px is waiting as Lx, so since P1 is waiting
654 the dependency Lx -> Lx+1, and since Px is waiting for Px+1 to release Lx,
|
| D | rt-mutex-design.rst | 40 Now there's no way of knowing how long A will be sleeping waiting for C
110 waiter is sometimes used in reference to the task that is waiting
117 - The highest priority process waiting on a specific mutex.
120 - The highest priority process waiting on one of the mutexes
214 is waiting on a mutex that is owned by the task. So if the task has
357 priority process that is waiting any of mutexes owned by the task. Since
376 always contains the highest priority task that is waiting on a mutex owned
460 (highest priority task waiting on the lock) is added to this task's
479 highest priority process currently waiting on this mutex, then we remove the
|
| D | hwspinlock.rst | 105 waiting for it to be released, but give up when the timeout elapses.
121 waiting for it to be released, but give up when the timeout elapses.
137 waiting for it to be released, but give up when the timeout elapses.
154 waiting for it to be released, but give up when the timeout elapses.
171 waiting for it to be released, but give up when the timeout elapses.
|
| /Documentation/accounting/ |
| D | taskstats-struct.rst | 112 /* Delay waiting for cpu, while runnable
120 /* Delay waiting for synchronous block I/O to complete
126 /* Delay waiting for page fault I/O (swap in only) */
193 /* Delay waiting for memory reclaim */
|
| D | delay-accounting.rst | 12 a) waiting for a CPU (while being runnable)
57 experienced by the task waiting for the corresponding resource
|
| /Documentation/process/ |
| D | volatile-considered-harmful.rst | 37 want to play with that data will be waiting on the lock. The spinlock
62 when the processor is busy-waiting on the value of a variable. The right
71 waiting is generally an anti-social act to begin with.
|
| /Documentation/networking/device_drivers/ethernet/toshiba/ |
| D | spider_net.rst | 31 and is waiting to be emptied and processed by the OS. A "not-in-use"
134 which, from the OS point of view, is empty; the OS will be waiting for
137 is a potential deadlock, with the OS waiting for one descr to fill,
138 while the hardware is waiting for a different set of descrs to become
160 as explained in the last section. The OS is waiting for descr 255 to
|
| /Documentation/block/ |
| D | stat.rst | 79 waited on this block device. If there are multiple I/O requests waiting,
101 on this block device. If there are multiple I/O requests waiting, this
103 number of requests waiting (see "read ticks" above for an example).
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | blkio-controller.rst | 179 Total amount of time the IOs for this cgroup spent waiting in the
182 measure of total time the cgroup spent waiting but rather a measure of
184 this metric does not include the time spent waiting for service once
215 waiting in the scheduler queue. This is in nanoseconds. If this is
216 read when the cgroup is in a waiting (for timeslice) state, the stat
|
| /Documentation/devicetree/bindings/sound/ |
| D | rt5660.txt | 22 added delay time for waiting codec power ready.
|
| /Documentation/userspace-api/media/dvb/ |
| D | dmx-set-filter.rst | 42 operation should be started immediately (without waiting for a
|
| /Documentation/usb/ |
| D | dwc3.rst | 46 handles the remaining EP work which might sleep such as waiting
|
| /Documentation/devicetree/bindings/power/reset/ |
| D | gpio-poweroff.yaml | 19 the system is still running after waiting some time (timeout-ms).
|
12345678