| /Linux-v4.19/Documentation/block/ |
| D | stat.txt | 23 read I/Os requests number of read I/Os processed
24 read merges requests number of read I/Os merged with in-queue I/O
26 read ticks milliseconds total wait time for read requests
27 write I/Os requests number of write I/Os processed
28 write merges requests number of write I/Os merged with in-queue I/O
30 write ticks milliseconds total wait time for write requests
31 in_flight requests number of I/Os currently in flight
33 time_in_queue milliseconds total wait time for all requests
34 discard I/Os requests number of discard I/Os processed
35 discard merges requests number of discard I/Os merged with in-queue I/O
[all …]
|
| D | writeback_cache_control.txt | 17 a forced cache flush, and the Force Unit Access (FUA) flag for requests.
26 guarantees that previously completed write requests are on non-volatile
58 on non-empty bios can simply be ignored, and REQ_PREFLUSH requests without
68 support required, the block layer completes empty REQ_PREFLUSH requests before
70 requests that have a payload. For devices with volatile write caches the
76 and handle empty REQ_OP_FLUSH requests in its prep_fn/request_fn. Note that
77 REQ_PREFLUSH requests with a payload are automatically turned into a sequence
84 and the driver must handle write requests that have the REQ_FUA bit set
|
| D | cfq-iosched.txt | 5 I/O bandwidth for all the processes which requests an I/O operation.
8 operation(synchronous requests). In case of asynchronous requests, all the
9 requests from all the processes are batched together according to their
45 This parameter allows the scheduler to anticipate requests in the "backward"
53 request, then the seeking cost of two requests is considered equivalent.
60 This parameter is used to set the timeout of asynchronous requests. Default
65 This parameter is used to set the timeout of synchronous requests. Default
66 value of this is 124ms. In case to favor synchronous requests over asynchronous
78 Not idling on individual queues in the group will dispatch requests from
97 latency mode is enabled. It will ensure that sync requests have an estimated
[all …]
|
| D | deadline-iosched.txt | 33 fifo_batch (number of requests)
39 maximum number of requests per batch.
50 When we have to move requests from the io scheduler queue to the block
67 front merge requests. Setting front_merges to 0 disables this functionality.
|
| /Linux-v4.19/Documentation/devicetree/bindings/dma/ |
| D | lpc1850-dmamux.txt | 11 - dma-requests: Number of DMA requests for the mux
15 - dma-requests: Number of DMA requests the controller can handle
28 dma-requests = <16>;
40 dma-requests = <64>;
|
| D | stm32-dmamux.txt | 17 - dma-channels : Number of DMA requests supported.
18 - dma-requests : Number of DMAMUX requests supported.
41 dma-requests = <8>;
61 dma-requests = <8>;
69 dma-requests = <128>;
|
| D | ti-dma-crossbar.txt | 9 - dma-requests: Number of DMA requests the crossbar can receive
13 - dma-requests: Number of DMA requests the controller can handle
43 dma-requests = <127>;
51 dma-requests = <205>;
|
| D | fsl-imx-dma.txt | 17 - #dma-requests : Number of DMA requests supported.
32 Clients have to specify the DMA requests with phandles in a list.
38 - dma-names: List of string identifiers for the DMA requests. For the correct
|
| D | dma.txt | 17 - dma-requests: Number of DMA request signals supported by the
31 dma-requests = <127>;
38 integrated with DMA requests than what the DMA controller can handle directly.
48 - dma-requests: Number of incoming request lines the router can handle.
50 - dma-requests: The router driver might need to look for this in order
58 dma-requests = <205>;
|
| D | stm32-dma.txt | 4 supporting 8 independent DMA channels. Each channel can have up to 8 requests.
16 - dma-requests : Number of DMA requests supported.
38 dma-requests = <8>;
|
| D | arm-pl330.txt | 17 - dma-requests: contains the total number of DMA requests supported by the DMAC
28 #dma-requests = <32>;
|
| /Linux-v4.19/Documentation/virtual/kvm/ |
| D | vcpu-requests.rst | 12 /* Check if any requests are pending for VCPU @vcpu. */
38 as possible after making the request. This means most requests
67 ensure VCPU requests are seen by VCPUs (see "Ensuring Requests Are Seen"),
88 certain VCPU requests, namely KVM_REQ_TLB_FLUSH, to wait until the VCPU
94 VCPU requests are simply bit indices of the ``vcpu->requests`` bitmap.
98 clear_bit(KVM_REQ_UNHALT & KVM_REQUEST_MASK, &vcpu->requests);
102 independent requests, all additional bits are available for architecture
103 dependent requests.
140 VCPU requests should be masked by KVM_REQUEST_MASK before using them with
150 This flag is applied to requests that only need immediate attention
[all …]
|
| /Linux-v4.19/arch/powerpc/kvm/ |
| D | trace.h | 108 __field( __u32, requests )
113 __entry->requests = vcpu->requests;
117 __entry->cpu_nr, __entry->requests)
|
| /Linux-v4.19/drivers/base/ |
| D | devtmpfs.c | 49 } *requests; variable
110 req.next = requests; in devtmpfs_create_node()
111 requests = &req; in devtmpfs_create_node()
140 req.next = requests; in devtmpfs_delete_node()
141 requests = &req; in devtmpfs_delete_node()
394 while (requests) { in devtmpfsd()
395 struct req *req = requests; in devtmpfsd()
396 requests = NULL; in devtmpfsd()
|
| /Linux-v4.19/Documentation/ABI/stable/ |
| D | sysfs-bus-xen-backend | 39 Number of flush requests from the frontend.
46 Number of requests delayed because the backend was too
47 busy processing previous requests.
54 Number of read requests from the frontend.
68 Number of write requests from the frontend.
|
| /Linux-v4.19/Documentation/scsi/ |
| D | hptiop.txt | 84 All queued requests are handled via inbound/outbound queue port.
99 - Post the packet to IOP by writing it to inbound queue. For requests
101 requests allocated in host memory, write (0x80000000|(bus_addr>>5))
108 For requests allocated in IOP memory, the request offset is posted to
111 For requests allocated in host memory, (0x80000000|(bus_addr>>5))
118 For requests allocated in IOP memory, the host driver free the request
121 Non-queued requests (reset/flush etc) can be sent via inbound message
129 All queued requests are handled via inbound/outbound list.
143 round to 0 if the index reaches the supported count of requests.
160 Non-queued requests (reset communication/reset/flush etc) can be sent via PCIe
|
| /Linux-v4.19/Documentation/ABI/testing/ |
| D | sysfs-class-scsi_tape | 33 The number of I/O requests issued to the tape drive other
34 than SCSI read/write requests.
54 Shows the total number of read requests issued to the tape
65 read I/O requests to complete.
85 Shows the total number of write requests issued to the tape
96 write I/O requests to complete.
|
| /Linux-v4.19/Documentation/device-mapper/ |
| D | log-writes.txt | 9 that is in the WRITE requests is copied into the log to make the replay happen
16 cache. This means that normal WRITE requests are not actually logged until the
21 This works by attaching all WRITE requests to a list once the write completes.
38 Any REQ_FUA requests bypass this flushing mechanism and are logged as soon as
39 they complete as those requests will obviously bypass the device cache.
41 Any REQ_DISCARD requests are treated like WRITE requests. Otherwise we would
42 have all the DISCARD requests, and then the WRITE requests and then the FLUSH
|
| /Linux-v4.19/Documentation/vm/ |
| D | balance.rst | 16 allocation requests that have order-0 fallback options. In such cases,
19 __GFP_IO allocation requests are made to prevent file system deadlocks.
21 In the absence of non sleepable allocation requests, it seems detrimental
26 That being said, the kernel should try to fulfill requests for direct
28 the dma pool, so as to keep the dma pool filled for dma requests (atomic
31 regular memory requests by allocating one from the dma pool, instead
76 probably because all allocation requests are coming from intr context
90 watermark[WMARK_HIGH]. When low_on_memory is set, page allocation requests will
99 1. Dynamic experience should influence balancing: number of failed requests
|
| /Linux-v4.19/Documentation/driver-api/firmware/ |
| D | request_firmware.rst | 12 Synchronous firmware requests
15 Synchronous firmware requests will wait until the firmware is found or until
38 Asynchronous firmware requests
41 Asynchronous firmware requests allow driver code to not have to wait
|
| /Linux-v4.19/Documentation/filesystems/ |
| D | gfs2-glocks.txt | 16 The gl_holders list contains all the queued lock requests (not
69 grant for which we ignore remote demote requests. This is in order to
151 1. DLM lock time (non-blocking requests)
152 2. DLM lock time (blocking requests)
157 currently means any requests when (a) the current state of
161 lock requests.
164 how many lock requests have been made, and thus how much data
168 of dlm lock requests issued.
186 the average time between lock requests for a glock means we
209 srtt - Smoothed round trip time for non-blocking dlm requests
[all …]
|
| /Linux-v4.19/Documentation/hid/ |
| D | hid-transport.txt | 101 - Control Channel (ctrl): The ctrl channel is used for synchronous requests and
104 events or answers to host requests on this channel.
108 SET_REPORT requests.
116 requiring explicit requests. Devices can choose to send data continuously or
119 to device and may include LED requests, rumble requests or more. Output
127 Feature reports are never sent without requests. A host must explicitly set
138 channel provides synchronous GET/SET_REPORT requests. Plain reports are only
146 simultaneous GET_REPORT requests.
155 GET_REPORT requests can be sent for any of the 3 report types and shall
169 multiple synchronous SET_REPORT requests.
[all …]
|
| /Linux-v4.19/Documentation/media/uapi/mediactl/ |
| D | media-func-ioctl.rst | 50 Macros and structures definitions specifying media ioctl requests and
52 requests, their respective function and parameters are specified in
63 Request-specific error codes are listed in the individual requests
|
| /Linux-v4.19/Documentation/media/uapi/cec/ |
| D | cec-func-ioctl.rst | 49 Macros and structures definitions specifying cec ioctl requests and
51 requests, their respective function and parameters are specified in
62 Request-specific error codes are listed in the individual requests
|
| /Linux-v4.19/drivers/gpu/drm/i915/selftests/ |
| D | mock_gem_device.c | 83 kmem_cache_destroy(i915->requests); in mock_device_release()
209 i915->requests = KMEM_CACHE(mock_request, in mock_gem_device()
213 if (!i915->requests) in mock_gem_device()
257 kmem_cache_destroy(i915->requests); in mock_gem_device()
|
