Searched full:requests (Results 1 – 25 of 367) sorted by relevance
12345678910>>...15
| /Documentation/block/ |
| D | stat.rst | 29 read I/Os requests number of read I/Os processed
30 read merges requests number of read I/Os merged with in-queue I/O
32 read ticks milliseconds total wait time for read requests
33 write I/Os requests number of write I/Os processed
34 write merges requests number of write I/Os merged with in-queue I/O
36 write ticks milliseconds total wait time for write requests
37 in_flight requests number of I/Os currently in flight
39 time_in_queue milliseconds total wait time for all requests
40 discard I/Os requests number of discard I/Os processed
41 discard merges requests number of discard I/Os merged with in-queue I/O
[all …]
|
| D | blk-mq.rst | 9 through queueing and submitting IO requests to block devices simultaneously,
23 involves ordering read/write requests according to the current position of the
32 The former design had a single queue to store block IO requests with a single
45 for instance), blk-mq takes action: it will store and manage IO requests to
53 layer or if we want to try to merge requests. In both cases, requests will be
56 Then, after the requests are processed by software queues, they will be placed
58 to process those requests. However, if the hardware does not have enough
59 resources to accept more requests, blk-mq will places requests on a temporary
65 The block IO subsystem adds requests in the software staging queues
73 The staging queue can be used to merge requests for adjacent sectors. For
[all …]
|
| D | writeback_cache_control.rst | 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 | deadline-iosched.rst | 32 fifo_batch (number of requests)
35 Requests are grouped into ``batches`` of a particular data direction (read or
38 maximum number of requests per batch.
49 When we have to move requests from the io scheduler queue to the block
66 front merge requests. Setting front_merges to 0 disables this functionality.
|
| /Documentation/virt/kvm/ |
| D | vcpu-requests.rst | 2 KVM VCPU Requests
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.
105 Architecture Independent Requests
[all …]
|
| /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 | 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 | 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 | mtk-uart-apdma.txt | 11 One interrupt per dma-requests, or 8 if no dma-requests property is present
13 - dma-requests: The number of DMA channels
50 dma-requests = <12>;
|
| D | dma-router.yaml | 18 have more peripherals integrated with DMA requests than what the DMA
31 dma-requests:
47 dma-requests = <205>;
|
| D | owl-dma.yaml | 41 dma-requests:
58 - dma-requests
75 dma-requests = <46>;
|
| /Documentation/filesystems/ |
| D | virtiofs.rst | 58 Since the virtio-fs device uses the FUSE protocol for file system requests, the
64 FUSE requests are placed into a virtqueue and processed by the host. The
71 prioritize certain requests over others. Virtqueues have queue semantics and
72 it is not possible to change the order of requests that have been enqueued.
74 impossible to add high priority requests. In order to address this difference,
75 the virtio-fs device uses a "hiprio" virtqueue specifically for requests that
76 have priority over normal requests.
|
| D | gfs2-glocks.rst | 19 The gl_holders list contains all the queued lock requests (not
78 grant for which we ignore remote demote requests. This is in order to
164 1. DLM lock time (non-blocking requests)
165 2. DLM lock time (blocking requests)
170 currently means any requests when (a) the current state of
174 lock requests.
177 how many lock requests have been made, and thus how much data
181 of dlm lock requests issued.
199 the average time between lock requests for a glock means we
226 srtt Smoothed round trip time for non blocking dlm requests
[all …]
|
| /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
|
| /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.
|
| D | sysfs-driver-ppi | 61 for the requests defined by TCG, i.e. requests from 1 to 22.
72 for the verdor specific requests, i.e. requests from 128 to
|
| D | debugfs-hisi-sec | 80 Description: Dump the total number of sent requests.
86 Description: Dump the total number of received requests.
92 Description: Dump the total number of requests sent with returning busy.
98 Description: Dump the total number of BD type error requests
105 Description: Dump the total number of invalid requests being received.
111 Description: Dump the total number of completed but marked error requests
|
| /Documentation/admin-guide/device-mapper/ |
| D | log-writes.rst | 10 that is in the WRITE requests is copied into the log to make the replay happen
17 cache. This means that normal WRITE requests are not actually logged until the
22 This works by attaching all WRITE requests to a list once the write completes.
39 Any REQ_FUA requests bypass this flushing mechanism and are logged as soon as
40 they complete as those requests will obviously bypass the device cache.
42 Any REQ_OP_DISCARD requests are treated like WRITE requests. Otherwise we would
43 have all the DISCARD requests, and then the WRITE requests and then the FLUSH
|
| /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.
|
| /Documentation/filesystems/nfs/ |
| D | rpc-cache.rst | 35 - making requests to user-space to fill in cache entries
37 - delaying RPC requests that depend on as-yet incomplete
38 cache entries, and replaying those requests when the cache entry
153 Each cache can treat the write requests differently, but it is
167 user-space. These requests appear in the channel file.
169 Successive reads will return successive requests.
170 If there are no more requests to return, read will return EOF, but a
182 If it dies and needs to be restarted, any requests that have not been
196 active readers for more than 60 seconds, further requests will not be
205 While each cache is free to use its own format for requests
|
| /Documentation/hid/ |
| D | hid-transport.rst | 105 - Control Channel (ctrl): The ctrl channel is used for synchronous requests and
108 events or answers to host requests on this channel.
112 SET_REPORT requests.
120 requiring explicit requests. Devices can choose to send data continuously or
123 to device and may include LED requests, rumble requests or more. Output
131 Feature reports are never sent without requests. A host must explicitly set
142 channel provides synchronous GET/SET_REPORT requests. Plain reports are only
150 simultaneous GET_REPORT requests.
159 GET_REPORT requests can be sent for any of the 3 report types and shall
173 multiple synchronous SET_REPORT requests.
[all …]
|
| /Documentation/userspace-api/media/cec/ |
| D | cec-func-ioctl.rst | 47 Macros and structures definitions specifying cec ioctl requests and
49 requests, their respective function and parameters are specified in
59 Request-specific error codes are listed in the individual requests
|
| /Documentation/userspace-api/media/mediactl/ |
| D | media-func-ioctl.rst | 47 Macros and structures definitions specifying media ioctl requests and
49 requests, their respective function and parameters are specified in
59 Request-specific error codes are listed in the individual requests
|
| /Documentation/scsi/ |
| D | hptiop.rst | 110 All queued requests are handled via inbound/outbound queue port.
121 Requests allocated in host memory must be aligned on 32-bytes boundary.
125 - Post the packet to IOP by writing it to inbound queue. For requests
127 requests allocated in host memory, write (0x80000000|(bus_addr>>5))
134 For requests allocated in IOP memory, the request offset is posted to
137 For requests allocated in host memory, (0x80000000|(bus_addr>>5))
144 For requests allocated in IOP memory, the host driver free the request
147 Non-queued requests (reset/flush etc) can be sent via inbound message
155 All queued requests are handled via inbound/outbound list.
161 Requests allocated in host memory must be aligned on 32-bytes boundary.
[all …]
|
| /Documentation/powerpc/ |
| D | vas-api.rst | 20 then requests can be submitted directly without kernel involvement.
21 Requests to the GZIP engine must be formatted as a co-processor Request
26 The GZIP engine provides two priority levels of requests: Normal and
27 High. Only Normal requests are supported from userspace right now.
31 requests directly to NX accelerator.
46 The application can then submit one or more requests to the engine by
52 Note that applications can send several requests with the same window or
208 Applications should format requests to the co-processor using the
210 of CRB and use NX from userspace such as sending requests and checking
216 Applications send requests to NX and wait for the status by polling on
[all …]
|
12345678910>>...15