Lines Matching +full:always +full:- +full:running

16 Documentation/scheduler/sched-eevdf.rst.
19 an "ideal, precise multi-tasking CPU" on real hardware.
21 "Ideal multi-tasking CPU" is a (non-existent  :-)) CPU that has 100% physical
23 1/nr_running speed.  For example: if there are 2 tasks running, then it runs
24 each at 50% physical power --- i.e., actually in parallel.
29 multi-tasking CPU described above.  In practice, the virtual runtime of a task
30 is its actual runtime normalized to the total number of running tasks.
37 In CFS the virtual runtime is expressed and tracked via the per-task
38 p->se.vruntime (nanosec-unit) value.  This way, it's possible to accurately
42    p->se.vruntime value --- i.e., tasks would execute simultaneously and no task
45 CFS's task picking logic is based on this p->se.vruntime value and it is thus
46 very simple: it always tries to run the task with the smallest p->se.vruntime
47 value (i.e., the task which executed least so far).  CFS always tries to split
52 with a few add-on embellishments like nice levels, multiprocessing and various
61 runqueues, but it uses a time-ordered rbtree to build a "timeline" of future
65 CFS also maintains the rq->cfs.min_vruntime value, which is a monotonic
71 The total number of running tasks in the runqueue is accounted through the
72 rq->cfs.load value, which is the sum of the weights of the tasks queued on the
75 CFS maintains a time-ordered rbtree, where all runnable tasks are sorted by the
76 p->se.vruntime key. CFS picks the "leftmost" task from this tree and sticks to it.
78 more and more to the right --- slowly but surely giving a chance for every task
85 p->se.vruntime.  Once p->se.vruntime gets high enough so that another task
86 becomes the "leftmost task" of the time-ordered rbtree it maintains (plus a
88 do not over-schedule tasks and trash the cache), then the new leftmost task is
112 chew.c, ring-test.c, massive_intr.c all work fine and do not impact
119 SMP load-balancing has been reworked/sanitized: the runqueue-walking
120 assumptions are gone from the load-balancing code now, and iterators of the
131   - SCHED_NORMAL (traditionally called SCHED_OTHER): The scheduling
134   - SCHED_BATCH: Does not preempt nearly as often as regular tasks
139   - SCHED_IDLE: This is even weaker than nice 19, but its not a true
146 The command chrt from util-linux-ng 2.13.1.1 can set all of these except
172  - enqueue_task(...)
175    It puts the scheduling entity (task) into the red-black tree and
178  - dequeue_task(...)
181    corresponding scheduling entity out of the red-black tree.  It decrements
184  - yield_task(...)
188    entity at the right-most end of the red-black tree.
190  - wakeup_preempt(...)
193    preempt the currently running task.
195  - pick_next_task(...)
199  - set_next_task(...)
204  - task_tick(...)
207    process switch.  This drives the running preemption.
224 CONFIG_RT_GROUP_SCHED permits to group real-time (i.e., SCHED_FIFO and
232    Documentation/admin-guide/cgroup-v1/cgroups.rst for more information about this filesystem.
238 	# mount -t tmpfs cgroup_root /sys/fs/cgroup
240 	# mount -t cgroup -ocpu none /sys/fs/cgroup/cpu