Lines Matching refs:of

4 The main aim of CFQ scheduler is to provide a fair allocation of the disk
8 operation(synchronous requests). In case of asynchronous requests, all the
23 single spindle SATA/SAS disks where we can cut down on overall number of
29 side is that isolation provided from WRITES also goes down and notion of
33 In general I think for SATA/SAS disks and software RAID of SATA/SAS disks
42 The distance is the amount of space from the current head location to the
43 sectors that are backward in terms of distance.
51 This parameter is used to compute the cost of backward seeking. If the
52 backward distance of request is just 1/back_seek_penalty from a "front"
53 request, then the seeking cost of two requests is considered equivalent.
56 will bias toward front request). Default value of back_seek_penalty is 2.
60 This parameter is used to set the timeout of asynchronous requests. Default
61 value of this is 248ms.
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
71 This parameter forces idling at the CFQ group level instead of CFQ
86 This parameter is used to enable/disable the latency mode of the CFQ
100 then to meet the latency constraints, throughput may decrease because of less
112 This parameter is same as of slice_sync but for asynchronous queue. The
117 This parameter is used to limit the dispatching of asynchronous request to
118 device request queue in queue's slice time. The maximum number of request that
125 executed for a certain amount of time(time_slice) before switching to another
126 queue. This parameter is used to calculate the time slice of synchronous
131 time_slice of synchronous queue, increase the value of slice_sync. Default
136 This specifies the number of request dispatched to the device queue. In a
137 queue's time slice, a request will not be dispatched if the number of request
141 In case of storage with several disk, this setting can limit the parallel
142 processing of request. Therefore, increasing the value can improve the
143 performance although this can cause the latency of some I/O to increase due
144 to more number of requests.
161 composed of five cgroups - root, A, B, AA and AB - with the following
174 compete with. They always get 100% of what the cgroup won at the
213 What is possible though is to measure number of requests dispatched from a
215 This effectively becomes the fairness in terms of IOPS (IO operations per
219 to IOPS mode and starts providing fairness in terms of number of requests
226 on same queue after completion of a request. In this process CFQ will not
229 The rationale behind idling is that it can cut down on number of seeks
231 sequential reads (next read will come on only after completion of previous
246 of queues or the tree. So if there are 4 queues waiting for IO to dispatch
255 flight at a time), then it cuts down on idling of individual queues and
265     queues. Otherwise in presence of many sequential readers, other
266     synchronous IO might not get fair share of disk.
270     roughly after 1 second. If after completion of REQ_NOIDLE request we
271     do not idle, and after a couple of milli seconds a another REQ_NOIDLE
276     fsync can generate dependent IO where bunch of data is written in the
277     context of fsync, and later some journaling data is written. Journaling
282     badly in presence of multiple sequential readers.
292     most of the cases.