Lines Matching full:performance

11 feature that allows user space to help in managing the performance requirement
16 performance requirements and restrictions of the tasks, thus it helps the
23 system run at a certain performance point.
26 performance constraints. It consists of two tunables:
31 These two bounds will ensure a task will operate within this performance range
36 performance point to operate at to deliver the desired user experience. Or one
38 much resources and should not go above a specific performance point. Viewing
39 the uclamp values as performance points rather than utilization is a better
44 performance point required by its display pipeline to ensure no frame is
58 resources background tasks are consuming by capping the performance point they
78 By making these uclamp performance requests, or rather hints, user space can
86 performance point will suffer a delay of ~200ms (PELT HALFIFE = 32ms) for the
90 UCLAMP_MIN=1024 will ensure such tasks will always see the highest performance
94 experience/performance and stretches to help achieve a better overall
95 performance/watt if used effectively.
103 performance point rather than being tied to MAX frequency all the time. Which
131 performance point for a task to run on, it must be able to influence the
268 highest performance point.
271 the task that needs the highest performance point gets it even if there's
330 Uclamp performance request has the range of 0 to 1024 inclusive.
345 * sched_util_min: requests the minimum performance point the system should run
346   at when this task is running. Or lower performance bound.
347 * sched_util_max: requests the maximum performance point the system should run
348   at when this task is running. Or upper performance bound.
358 starts at 40% performance level**. If the task runs for a long enough time so
359 that its actual utilization goes above 80%, the utilization, or performance
463 rqs are restricted too. IOW, the whole system is capped to half its performance
466 This is useful to restrict the overall maximum performance point of the system.
467 For example, it can be handy to limit performance when running low on battery
468 or when the system wants to limit access to more energy hungry performance
488 That is, by default they're boosted to run at the maximum performance point of
499 That is by default they're boosted to run at the maximum performance point of
510 Running RT tasks at maximum performance point is expensive on battery powered
511 devices and not necessary. To allow system developer to offer good performance
513 performance point, this sysctl knob allows tuning the best boost value to
515 performance point all the time.
518 to ensure they are performance and power aware. Ideally this knob should be set
519 to 0 by system designers and leave the task of managing performance
525 Util clamp promotes the concept of user space assisted power and performance
553 to ensure on next wake up it runs at a higher performance point. It should try
560 **Generally it is advised to perceive the input as performance level or point
567 UCLAMP_MAX for some background tasks that don't care about performance but
574 operating at the higher performance points which are usually energy
581 4.4. Per-app performance restriction
585 app every time it is executed to guarantee a minimum performance point and/or
586 limit it from draining system power at the cost of reduced performance for
590 compiling the kernel and happy to sacrifice performance to save power, but
591 still would like to keep your browser performance intact, uclamp makes it
608 and it shares the rq with p1 which is free to run at any performance point:
614 then due to max aggregation the rq will be allowed to reach max performance
626 from the rq although p1, which is allowed to run at any performance point,
713 and run somewhere near mid performance point of that CPU, not the Fmax we get.
728 performance point when it wakes up and starts running, then all these