| /linux/Documentation/block/ |
| H A 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 …]
|
| H A 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 place 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 …]
|
| H A 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
53 support required, the block layer completes empty REQ_PREFLUSH requests before
55 requests that have a payload.
88 When the BLK_FEAT_WRITE_CACHE flag is set, REQ_OP_WRITE | REQ_PREFLUSH requests
|
| /linux/Documentation/admin-guide/perf/ |
| H A D | fujitsu_uncore_pmu.rst | 34 This event counts the number of read requests to MAC.
36 This event counts the number of read requests including retry to MAC.
38 This event counts the number of responses to read requests to MAC.
40 This event counts the number of read requests including retry with PFTGT
43 This event counts the number of read requests including retry without PFTGT
46 This event counts the number of responses to read requests which hit the
49 This event counts the number of responses to read requests which miss the
52 This event counts outstanding read requests issued by DDR memory controller
55 This event counts the number of write requests to MAC (including zero write,
58 This event counts the number of full write requests to MAC (not including
[all …]
|
| /linux/Documentation/virt/acrn/ |
| H A D | io-request.rst | 14 For each User VM, there is a shared 4-KByte memory region used for I/O requests
26 An I/O client is responsible for handling User VM I/O requests whose accessed
29 default client, that handles all I/O requests that do not fit into the range of
33 Below illustration shows the relationship between I/O requests shared buffer,
34 I/O requests and I/O clients.
84 4. Processing flow of I/O requests
91 c. The upcall handler schedules a worker to dispatch I/O requests.
92 d. The worker looks for the PENDING I/O requests, assigns them to different
95 e. The notified client handles the assigned I/O requests.
96 f. The HSM updates I/O requests states to COMPLETE and notifies the hypervisor
|
| /linux/drivers/gpu/drm/i915/gt/uc/ |
| H A D | intel_guc_ct.c | 145 spin_lock_init(&ct->requests.lock); in intel_guc_ct_init_early()
146 INIT_LIST_HEAD(&ct->requests.pending); in intel_guc_ct_init_early()
147 INIT_LIST_HEAD(&ct->requests.incoming); in intel_guc_ct_init_early()
151 INIT_WORK(&ct->requests.worker, ct_incoming_request_worker_func); in intel_guc_ct_init_early()
407 unsigned int lost = fence % ARRAY_SIZE(ct->requests.lost_and_found); in ct_track_lost_and_found()
415 ct->requests.lost_and_found[lost].stack = stack_depot_save(entries, n, GFP_NOWAIT); in ct_track_lost_and_found()
417 ct->requests.lost_and_found[lost].fence = fence; in ct_track_lost_and_found()
418 ct->requests.lost_and_found[lost].action = action; in ct_track_lost_and_found()
425 return ++ct->requests.last_fence; in ct_get_next_fence()
765 spin_lock(&ct->requests.lock); in ct_send()
[all …]
|
| /linux/Documentation/virt/kvm/ |
| H A D | vcpu-requests.rst | 14 /* Check if any requests are pending for VCPU @vcpu. */
40 as possible after making the request. This means most requests
69 ensure VCPU requests are seen by VCPUs (see "Ensuring Requests Are Seen"),
90 certain VCPU requests, namely KVM_REQ_TLB_FLUSH, to wait until the VCPU
96 VCPU requests are simply bit indices of the ``vcpu->requests`` bitmap.
100 clear_bit(KVM_REQ_UNBLOCK & KVM_REQUEST_MASK, &vcpu->requests);
104 independent requests; all additional bits are available for architecture
105 dependent requests.
142 VCPU requests should be masked by KVM_REQUEST_MASK before using them with
152 This flag is applied to requests that only need immediate attention
[all …]
|
| /linux/Documentation/devicetree/bindings/dma/ |
| H A 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>;
|
| /linux/Documentation/filesystems/fuse/ |
| H A D | fuse-io-uring.rst | 16 As of now not all requests types are supported through io-uring, userspace
17 is required to also handle requests through /dev/fuse after io-uring setup
24 Fuse kernel requests are queued through the classical /dev/fuse
38 the requests and also marks the entry available again. If there are
39 pending requests waiting the request will be immediately submitted
58 Sending requests with CQEs
|
| /linux/Documentation/filesystems/ |
| H A 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.
|
| /linux/arch/powerpc/kvm/ |
| H A D | trace.h | 106 __field( __u32, requests )
111 __entry->requests = vcpu->requests;
115 __entry->cpu_nr, __entry->requests)
|
| /linux/Documentation/ABI/stable/ |
| H A 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/Documentation/admin-guide/device-mapper/ |
| H A 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
|
| H A D | dm-crypt.rst | 102 Block discard requests (a.k.a. TRIM) are passed through the crypt device.
103 The default is to ignore discard requests.
130 Bypass dm-crypt internal workqueue and process read requests synchronously.
133 Bypass dm-crypt internal workqueue and process write requests synchronously.
175 Maximum size of read requests. When a request larger than this size
177 concurrency (the split requests could be encrypted in parallel by multiple
182 Maximum size of write requests. When a request larger than this size
184 concurrency (the split requests could be encrypted in parallel by multiple
|
| /linux/Documentation/ABI/testing/ |
| H A 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/Documentation/scsi/ |
| H A D | hptiop.rst | 110 All queued requests are handled via inbound/outbound queue port.
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.
169 round to 0 if the index reaches the supported count of requests.
186 Non-queued requests (reset communication/reset/flush etc) can be sent via PCIe
|
| /linux/Documentation/hid/ |
| H A 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 …]
|
| /linux/Documentation/driver-api/firmware/ |
| H A D | request_firmware.rst | 12 Synchronous firmware requests
15 Synchronous firmware requests will wait until the firmware is found or until
43 Asynchronous firmware requests
46 Asynchronous firmware requests allow driver code to not have to wait
|
| /linux/drivers/media/v4l2-core/ |
| H A D | v4l2-ctrls-request.c | 21 INIT_LIST_HEAD(&hdl->requests); in v4l2_ctrl_handler_init_request()
39 if (hdl->req_obj.ops || list_empty(&hdl->requests)) in v4l2_ctrl_handler_free_request()
47 list_for_each_entry_safe(req, next_req, &hdl->requests, requests) { in v4l2_ctrl_handler_free_request()
102 list_del_init(&hdl->requests); in v4l2_ctrl_request_unbind()
163 list_add_tail(&hdl->requests, &from->requests); in v4l2_ctrl_request_bind()
|
| /linux/drivers/gpu/drm/i915/gem/ |
| H A D | i915_gem_execbuffer.c | 259 struct i915_request *requests[MAX_ENGINE_INSTANCE + 1]; member
1978 if (eb->requests[i]) in eb_find_first_request_added()
1979 return eb->requests[i]; in eb_find_first_request_added()
2028 struct i915_request *rq = eb->requests[j]; in eb_capture_commit()
2132 if (!eb->requests[j]) in eb_move_to_gpu()
2135 err = _i915_vma_move_to_active(vma, eb->requests[j], in eb_move_to_gpu()
2139 &eb->requests[j]->fence, in eb_move_to_gpu()
2172 if (!eb->requests[j]) in eb_move_to_gpu()
2175 i915_request_set_error_once(eb->requests[j], err); in eb_move_to_gpu()
2426 if (!eb->requests[i]) in eb_submit()
[all …]
|
| /linux/net/handshake/ |
| H A D | netlink.c | 198 LIST_HEAD(requests); in handshake_net_exit()
207 list_splice_init(&requests, &hn->hn_requests); in handshake_net_exit()
210 while (!list_empty(&requests)) { in handshake_net_exit()
211 req = list_first_entry(&requests, struct handshake_req, hr_list); in handshake_net_exit()
|
| /linux/Documentation/usb/ |
| H A D | raw-gadget.rst | 24 GadgetFS responds to some USB requests internally based on the provided
25 descriptors. Note that the UDC driver might respond to some requests on
28 2. Raw Gadget allows providing arbitrary data as responses to USB requests,
31 responses to USB requests.
91 requests).
|
| /linux/Documentation/userspace-api/media/mediactl/ |
| H A 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
|
| /linux/Documentation/userspace-api/media/cec/ |
| H A 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
|
| /linux/Documentation/arch/powerpc/ |
| H A D | vas-api.rst | 20 then requests can be submitted directly without kernel involvement.
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
247 but other threads can send requests to NX using this window. These
[all …]
|