Lines Matching full:requests

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
74 instance, requests for sector 3-6, 6-7, 7-9 can become one request for 3-9.
76 to sequential access, grouped requests for sequential access decreases the
77 number of individual requests. This technique of merging requests is called
80 Along with that, the requests can be reordered to ensure fairness of system
92 happens only between requests in the same queue, so it is not possible to merge
93 requests from different queues, otherwise there would be cache trashing and a
94 need to have a lock for each queue. After the scheduling, the requests are
97 place requests on whatever software queue the process is running on, without
98 any reordering. When the device starts processing requests in the hardware
109 block layer removes requests from the associated software queues and tries to
112 If it's not possible to send the requests directly to hardware, they will be
113 added to a linked list (``hctx->dispatch``) of requests. Then,
114 next time the block layer runs a queue, it will send the requests laying at the
116 requests that were ready to be sent first. The number of hardware queues
120 hardware queues to send requests for.
125         the order of completion of requests. This must be handled by