Lines Matching defs:new
400 * update tmp_alone_branch to points to the new begin
790 /* Give new sched_entity start runnable values to heavy its load in infant time */
813 * With new tasks being created, their initial util_avgs are extrapolated
1101 * We are picking a new current task - update its stats:
1106 * We are starting a new run period:
2325 * stats only if the task is so new there are no NUMA statistics yet.
2549 /* Set the new preferred node */
3070 * has completed. This is most likely due to a new task that
3463 * date and ready to go to new CPU/cfs_rq. But we have difficulty in
3579 /* Set new sched_entity's utilization */
3604 /* Set new sched_entity's runnable */
3641 * Estimate the new unweighted runnable_sum of the gcfs_rq by
3804 * Check that util_sum is still above its lower bound for the new
3861 * Hell(o) Nasty stuff.. we need to recompute _sum based on the new
3932 * Track task load average for carrying it to new CPU after migrated, and
3948 * IOW we're enqueueing a task on a new CPU.
4202 * Where 'w' is the weight of new samples, which is configured to be
4337 * however the extra weight of the new task will slow them down a
4338 * little, place the new task so that it fits in the slot that
4445 * - For group_entity, update its weight to reflect the new share of
4447 * - Add its new weight to cfs_rq->load.weight
4545 * - For group entity, update its weight to reflect the new share
5246 * unthrottle, this also covers the case in which the new bandwidth is
5477 u64 new, old = ktime_to_ns(cfs_b->period);
5484 new = old * 0x2;
5485 if (new < max_cfs_quota_period) {
5486 cfs_b->period = ns_to_ktime(new);
5489 pr_warn_ratelimited("cfs_period_timer[cpu%d]: period too short, scaling up (new cfs_period_us = %lld, "
5491 smp_processor_id(), div_u64(new, NSEC_PER_USEC),
5608 * in take_cpu_down(), so we prevent new cfs throttling here.
5864 * Since new tasks are assigned an initial util_avg equal to
5869 * for the first enqueue operation of new tasks during the
6023 /* Task has no contribution or is new */
6047 /* Task has no contribution or is new */
6700 * cfs.avg.util_avg or just after migrating tasks and new task wakeups until
6701 * the average stabilizes with the new running time. We need to check that the
6764 /* Task has no contribution or is new */
6985 * bias new tasks towards specific types of CPUs first, or to try to infer
7188 * Called immediately before a task is migrated to a new CPU; task_cpu(p) and
7196 * deal with this by subtracting the old and adding the new
7198 * the task on the new runqueue.
7230 * its up to date and ready to go to new CPU/cfs_rq. But we
7239 /* Tell new CPU we are migrated */
7397 * We can come here with TIF_NEED_RESCHED already set from new task
7773 * In order to avoid CPUs going idle while there's still work to do, new idle
8294 * attach_task() -- attach the task detached by detach_task() to its new rq.
8307 * its new rq.
8321 * new rq.
9193 /* Task has no contribution or is new */
11023 * of nohz.has_blocked can only happen after checking the new load
11254 * 0 - failed, no new tasks
11255 * > 0 - success, new (fair) tasks present
11588 * 'current' within the tree based on its new key value.
11793 /* ensure bandwidth has been allocated on our new cfs_rq */