Lines Matching defs:new
903 struct rb_node **new = &(root->rb_root.rb_node), *parent = NULL;
921 while (*new) {
922 struct bfq_weight_counter *__counter = container_of(*new,
925 parent = *new;
932 new = &((*new)->rb_left);
934 new = &((*new)->rb_right);
958 rb_link_node(&bfqq->weight_counter->weights_node, parent, new);
1054 * bfq_updated_next_req - update the queue after a new next_rq selection.
1087 bfq_log_bfqq(bfqd, bfqq, "updated next rq: new budget %lu",
1216 * Start the creation of a new burst list only if there is no
1256 * new queue being activated shortly after the last queue
1295 * these new queues from. If there no other active queues, then
1296 * weight-raising these new queues just lowers throughput in most
1347 * at which a new queue entered the burst list, then the function appends
1379 * in a possible new burst (then the burst list contains just Q
1440 * possible new burst to start. In particular, in the second
1441 * case, bfqq has become the first queue in the possible new
1494 * and did not make it to issue a new request before its last
1498 * a new request before the expiration of the idling-time.
1546 * the hole, if: 1) the process is waiting for the arrival of a new
1971 * was better to plug I/O dispatch, and to wait for a new
2008 * get new I/O enqueued---and then completed---before being
2017 * receive new I/O only after the I/O of the other queue is
2084 * receive new I/O only right after some I/O request of the other
2090 * injecting the I/O of the waker queue, every time a new
2104 * still being served by the drive, and may receive new I/O on the completion
2192 * the woken_list of a new waker
2235 * The following conditions must hold to setup a new
2236 * sampling of total service time, and then a new
2279 * total service time, unless new injection
2531 * fit the new request and the queue's position in its
2801 * best option, as we feed the in-service queue with new
3358 * Get and set a new queue for service.
3378 * seeks. So allow a little bit of time for him to submit a new rq.
3428 bfq_log(bfqd, "new max_budget = %d", bfqd->bfq_max_budget);
3435 if (rq != NULL) { /* new rq dispatch now, reset accordingly */
3441 } else /* no new rq dispatched, just reset the number of samples */
3459 * not compute new rate. Just reset parameters, to get ready
3460 * for a new evaluation attempt.
3467 * If a new request completion has occurred after last
3497 * of the filter as a function of the 'weight' of the new
3605 * for computing a new peak rate (similarly to the late-
3612 * - start a new observation interval with this dispatch
3666 * incremented again when the (new) value of bfqq->dispatched
3781 * can still preempt the new in-service queue if the next
3803 * remaining idle, each queue receives very quickly a new
3838 * arrival of new I/O requests for bfqq (recall that bfqq is sync). If
3866 * sequence of events: (1) bfqq is expired, (2) a new queue with a
3867 * lower weight than bfqq becomes busy (or more queues), (3) the new
3868 * queue is served until a new request arrives for bfqq, (4) when bfqq
3869 * is finally served, there are so many requests of the new queue in
3909 * dispatched while bfqq is waiting for its new I/O to
4058 * new request in time to enjoy timestamp
4102 * If there is still backlog, then assign a new budget, making
4109 * it will be updated on the arrival of a new request.
4116 bfq_log_bfqq(bfqd, bfqq, "head sect: %u, new budget %d",
4132 * I/O pattern where a new request is dispatched only after the
4220 * the application stops issuing new requests until all its pending requests
4221 * have been completed. After that, the application may issue a new batch,
4447 * the bubble up of the new value of bfqq->entity.budget will
4469 * device idled) for the arrival of a new request, then we may incur
4633 * 2) the device must be idled to wait for the possible arrival of a new
4702 * (and re-added only if it gets new requests, but then it
4703 * is assigned again enough budget for its new backlog).
4799 * check whether to continue servicing it, or retrieve and set a new one.
4837 * than to return NULL and trigger a new dispatch to get a
4859 * not disable disk idling even when a new request
4864 * If we get here: 1) at least a new request
4885 * for a new request, or has requests waiting for a completion and
4920 * I/O needs to be completed for bfqq to receive new
4946 * dispatched while bfqq is waiting for new I/O.
4982 * i.e., the time before bfqq finally receives new I/O,
5023 bfq_log_bfqq(bfqd, bfqq, "select_queue: checking new queue");
5503 * Update the entity prio values; note that the new values will not
5750 * This new mechanism most certainly obsoletes the current
6002 * to receive new I/O. Details in the comments on the choice
6016 * bfqq to receive new I/O soon.
6021 * short. Without the 100 ms barrier, this new state change
6075 * Called when a new fs request (rq) is added to bfqq. Check if there's
6099 * for a new request from the in-service queue, we
6103 * unplug the device: hopefully, new requests will be
6122 * The queue is not empty, because a new request just
6272 * redirected into a new queue.
6389 * valid time interval for computing a new peak rate. Invoke
6527 * actually injected while bfqq is empty, and that a new request R
6716 * Returns NULL if a new bfqq should be allocated, or the old bfqq if this
6963 * to trigger the creation of new queues very close to when
7035 * different from the queue that was idling if a new request