Lines Matching defs:rate
247 /* Min number of samples required to perform peak-rate update */
249 /* Min observation time interval required to perform a peak-rate update (ns) */
251 /* Target observation time interval for a peak-rate update (ns) */
255 * Shift used for peak-rate fixed precision calculations.
258 * - the current type used to store rate: u32
259 * - the current unit of measure for rate: [sectors/usec], or, more precisely,
275 * where r is the peak rate of the device, and ref_rate and
277 * ref_rate is the peak rate of the reference storage device (see
296 * peak-rate estimator tends to yield slightly lower values than the
297 * actual peak rate (it can yield the actual peak rate only if there
333 * peak rate of the device, so as to be equal to the time needed to
350 * happens to be underestimating the device peak rate, and thus
727 * In most scenarios, the rate at which nodes are created/destroyed
1327 * estimated disk peak rate; otherwise return the default max budget
3035 * rate. This enables BFQ to utilize a full timeslice with a full
3036 * budget, even if the in-service queue is served at peak rate. And
3047 * function of the estimated peak rate. See comments on
3079 u32 rate, weight, divisor;
3086 * not compute new rate. Just reset parameters, to get ready
3095 * dispatch, then, to approximate the rate at which requests
3107 rate = div64_ul(bfqd->tot_sectors_dispatched<<BFQ_RATE_SHIFT,
3111 * Peak rate not updated if:
3113 * total, and rate is below the current estimated peak rate
3114 * - rate is unreasonably high (> 20M sectors/sec)
3117 rate <= bfqd->peak_rate) ||
3118 rate > 20<<BFQ_RATE_SHIFT)
3122 * We have to update the peak rate, at last! To this purpose,
3125 * measured rate.
3134 * the measured rate contributes for half of the next value of
3135 * the estimated peak rate.
3161 * Finally, update peak rate:
3163 * peak_rate = peak_rate * (divisor-1) / divisor + rate / divisor
3167 rate /= divisor; /* smoothing constant alpha = 1/divisor */
3169 bfqd->peak_rate += rate;
3187 * Update the read/write peak rate (the main quantity used for
3190 * It is not trivial to estimate the peak rate (correctly): because of
3195 * precisely at what rate a given set of requests is actually served
3199 * available, and, from this piece of information, the "dispatch rate"
3203 * unknown, namely in-device request service rate.
3205 * The main issue is that, because of the above facts, the rate at
3207 * interval can vary greatly with respect to the rate at which the
3214 * the next function to estimate the peak service rate as a function
3215 * of the observed dispatch rate. The function assumes to be invoked
3232 * for computing a new peak rate (similarly to the late-
3238 * - compute rate, if possible, for that observation interval
3745 * the real rate at which the I/O requests of each bfq_queue are
3799 * spikes in service rate estimation.
3806 * rate is likely to be an average over the disk
3809 * its rate has been lower than half of the estimated
3810 * peak rate.
3904 * 2) jiffies, instead of increasing at a constant rate, may stop increasing
3970 * estimated peak rate is actually an average over the disk
4169 * non-weight-raised queues ask for requests at a lower rate,
5670 * computing rate in next check.
5678 * rate (less than 1M sectors/sec), then the whole observation
5680 * valid time interval for computing a new peak rate. Invoke
5685 * - compute rate, if possible, for that observation interval
5769 * cumulative I/O at a lower rate than the rate at which the device
6524 * Approximate rate required
6533 * rate is equal to 2/3 of the highest reference rate.
6847 * estimated peak rate tends to be smaller than the actual
6848 * peak rate. The reason for this last fact is that estimates
6852 * scheduler cannot rely on a peak-rate-evaluation workload to