/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 …]
|
/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/Documentation/devicetree/bindings/dma/ |
H A 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>;
|
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/drivers/gpu/drm/i915/gt/uc/ |
H A D | intel_guc_ct.c | 144 spin_lock_init(&ct->requests.lock); in intel_guc_ct_init_early() 145 INIT_LIST_HEAD(&ct->requests.pending); in intel_guc_ct_init_early() 146 INIT_LIST_HEAD(&ct->requests.incoming); in intel_guc_ct_init_early() 150 INIT_WORK(&ct->requests.worker, ct_incoming_request_worker_func); in intel_guc_ct_init_early() 409 unsigned int lost = fence % ARRAY_SIZE(ct->requests.lost_and_found); in ct_track_lost_and_found() 417 ct->requests.lost_and_found[lost].stack = stack_depot_save(entries, n, GFP_NOWAIT); in ct_track_lost_and_found() 419 ct->requests.lost_and_found[lost].fence = fence; in ct_track_lost_and_found() 420 ct->requests.lost_and_found[lost].action = action; in ct_track_lost_and_found() 427 return ++ct->requests.last_fence; in ct_get_next_fence() 767 spin_lock(&ct->requests.lock); in ct_send() [all …]
|
/linux/drivers/gpu/drm/i915/gt/ |
H A D | intel_gt_requests.c | 21 list_for_each_entry_safe(rq, rn, &tl->requests, link) in retire_requests() 31 return !list_empty(&engine->kernel_context->timeline->requests); in engine_active() 208 container_of(work, typeof(*gt), requests.retire_work.work); in retire_work_handler() 210 queue_delayed_work(gt->i915->unordered_wq, >->requests.retire_work, in retire_work_handler() 217 INIT_DELAYED_WORK(>->requests.retire_work, retire_work_handler); in intel_gt_init_requests() 222 cancel_delayed_work(>->requests.retire_work); in intel_gt_park_requests() 227 queue_delayed_work(gt->i915->unordered_wq, >->requests.retire_work, in intel_gt_unpark_requests() 234 cancel_delayed_work_sync(>->requests.retire_work); in intel_gt_fini_requests()
|
/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/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.
|
H A D | gfs2-glocks.rst | 19 The gl_holders list contains all the queued lock requests (not 76 grant for which we ignore remote demote requests. This is in order to 160 1. DLM lock time (non-blocking requests) 161 2. DLM lock time (blocking requests) 166 currently means any requests when (a) the current state of 170 lock requests. 173 how many lock requests have been made, and thus how much data 177 of dlm lock requests issued. 195 the average time between lock requests for a glock means we 222 srtt Smoothed round trip time for non blocking dlm requests [all …]
|
/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/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/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
|
/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/mm/ |
H A D | balance.rst | 14 allocation requests that have order-0 fallback options. In such cases, 17 __GFP_IO allocation requests are made to prevent file system deadlocks. 19 In the absence of non sleepable allocation requests, it seems detrimental 24 That being said, the kernel should try to fulfill requests for direct 26 the dma pool, so as to keep the dma pool filled for dma requests (atomic 29 regular memory requests by allocating one from the dma pool, instead 74 probably because all allocation requests are coming from intr context 88 watermark[WMARK_HIGH]. When low_on_memory is set, page allocation requests will 97 1. Dynamic experience should influence balancing: number of failed requests
|
/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/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/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 1992 if (eb->requests[i]) in eb_find_first_request_added() 1993 return eb->requests[i]; in eb_find_first_request_added() 2042 struct i915_request *rq = eb->requests[j]; in eb_capture_commit() 2146 if (!eb->requests[j]) in eb_move_to_gpu() 2149 err = _i915_vma_move_to_active(vma, eb->requests[j], in eb_move_to_gpu() 2153 &eb->requests[j]->fence, in eb_move_to_gpu() 2186 if (!eb->requests[j]) in eb_move_to_gpu() 2189 i915_request_set_error_once(eb->requests[j], err); in eb_move_to_gpu() 2440 if (!eb->requests[i]) in eb_submit() [all …]
|
/linux/net/handshake/ |
H A D | netlink.c | 199 LIST_HEAD(requests); in handshake_net_exit() 208 list_splice_init(&requests, &hn->hn_requests); in handshake_net_exit() 211 while (!list_empty(&requests)) { in handshake_net_exit() 212 req = list_first_entry(&requests, struct handshake_req, hr_list); in handshake_net_exit()
|
/linux/drivers/base/ |
H A D | devtmpfs.c | 55 } *requests; variable 102 req->next = requests; in devtmpfs_submit_req() 103 requests = req; in devtmpfs_submit_req() 393 while (requests) { in devtmpfs_work_loop() 394 struct req *req = requests; in devtmpfs_work_loop() 395 requests = NULL; in devtmpfs_work_loop()
|
/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/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).
|