Lines Matching defs:new
734 struct rb_node **new = &(root->rb_root.rb_node), *parent = NULL;
752 while (*new) {
753 struct bfq_weight_counter *__counter = container_of(*new,
756 parent = *new;
763 new = &((*new)->rb_left);
765 new = &((*new)->rb_right);
789 rb_link_node(&bfqq->weight_counter->weights_node, parent, new);
937 * bfq_updated_next_req - update the queue after a new next_rq selection.
970 bfq_log_bfqq(bfqd, bfqq, "updated next rq: new budget %lu",
1085 * Start the creation of a new burst list only if there is no
1125 * new queue being activated shortly after the last queue
1164 * these new queues from. If there no other active queues, then
1165 * weight-raising these new queues just lowers throughput in most
1216 * at which a new queue entered the burst list, then the function appends
1248 * in a possible new burst (then the burst list contains just Q
1309 * possible new burst to start. In particular, in the second
1310 * case, bfqq has become the first queue in the possible new
1363 * and did not make it to issue a new request before its last
1367 * a new request before the expiration of the idling-time.
1415 * the hole, if: 1) the process is waiting for the arrival of a new
1829 * get new I/O enqueued---and then completed---before being
1838 * receive new I/O only after the I/O of the other queue is
1888 * remaining empty, happens to receive new I/O only
1896 * queue, every time a new bfq_dispatch_request
1969 * the woken_list of a new waker
2002 * The following conditions must hold to setup a new
2003 * sampling of total service time, and then a new
2046 * total service time, unless new injection
2306 * fit the new request and the queue's position in its
2553 * best option, as we feed the in-service queue with new
2985 * Get and set a new queue for service.
3005 * seeks. So allow a little bit of time for him to submit a new rq.
3055 bfq_log(bfqd, "new max_budget = %d", bfqd->bfq_max_budget);
3062 if (rq != NULL) { /* new rq dispatch now, reset accordingly */
3068 } else /* no new rq dispatched, just reset the number of samples */
3086 * not compute new rate. Just reset parameters, to get ready
3087 * for a new evaluation attempt.
3094 * If a new request completion has occurred after last
3124 * of the filter as a function of the 'weight' of the new
3232 * for computing a new peak rate (similarly to the late-
3239 * - start a new observation interval with this dispatch
3293 * incremented again when the (new) value of bfqq->dispatched
3408 * can still preempt the new in-service queue if the next
3430 * remaining idle, each queue receives very quickly a new
3465 * arrival of new I/O requests for bfqq (recall that bfqq is sync). If
3520 * dispatched while bfqq is waiting for its new I/O to
3669 * new request in time to enjoy timestamp
3713 * If there is still backlog, then assign a new budget, making
3720 * it will be updated on the arrival of a new request.
3727 bfq_log_bfqq(bfqd, bfqq, "head sect: %u, new budget %d",
3743 * I/O pattern where a new request is dispatched only after the
3832 * the application stops issuing new requests until all its pending requests
3833 * have been completed. After that, the application may issue a new batch,
4078 * the bubble up of the new value of bfqq->entity.budget will
4100 * device idled) for the arrival of a new request, then we may incur
4264 * 2) the device must be idled to wait for the possible arrival of a new
4331 * (and re-added only if it gets new requests, but then it
4332 * is assigned again enough budget for its new backlog).
4374 * check whether to continue servicing it, or retrieve and set a new one.
4403 * than to return NULL and trigger a new dispatch to get a
4425 * not disable disk idling even when a new request
4430 * If we get here: 1) at least a new request
4451 * for a new request, or has requests waiting for a completion and
4479 * I/O needs to be completed for bfqq to receive new
4533 * i.e., the time before bfqq finally receives new I/O,
4566 bfq_log_bfqq(bfqd, bfqq, "select_queue: checking new queue");
5009 * Update the entity prio values; note that the new values will not
5311 * to receive new I/O. Details in the comments on the choice
5325 * bfqq to receive new I/O soon.
5330 * short. Without the 100 ms barrier, this new state change
5384 * Called when a new fs request (rq) is added to bfqq. Check if there's
5408 * for a new request from the in-service queue, we
5412 * unplug the device: hopefully, new requests will be
5431 * The queue is not empty, because a new request just
5564 * redirected into a new queue.
5680 * valid time interval for computing a new peak rate. Invoke
5813 * actually injected while bfqq is empty, and that a new request R
5991 * Returns NULL if a new bfqq should be allocated, or the old bfqq if this
6212 * to trigger the creation of new queues very close to when
6284 * different from the queue that was idling if a new request