/Linux-v6.1/Documentation/admin-guide/cgroup-v1/ |
D | freezer-subsystem.rst | 6 and stop sets of tasks in order to schedule the resources of a machine 9 whole. The cgroup freezer uses cgroups to describe the set of tasks to 11 a means to start and stop the tasks composing the job. 14 of tasks. The freezer allows the checkpoint code to obtain a consistent 15 image of the tasks by attempting to force the tasks in a cgroup into a 16 quiescent state. Once the tasks are quiescent another task can 18 quiesced tasks. Checkpointed tasks can be restarted later should a 19 recoverable error occur. This also allows the checkpointed tasks to be 21 to another node and restarting the tasks there. 24 and resuming tasks in userspace. Both of these signals are observable [all …]
|
D | cpuacct.rst | 5 The CPU accounting controller is used to group tasks using cgroups and 6 account the CPU usage of these groups of tasks. 9 group accumulates the CPU usage of all of its child groups and the tasks 17 visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in 18 the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup. 20 by this group which is essentially the CPU time obtained by all the tasks 27 # echo $$ > g1/tasks 38 user: Time spent by tasks of the cgroup in user mode. 39 system: Time spent by tasks of the cgroup in kernel mode.
|
D | cgroups.rst | 45 tasks, and all their future children, into hierarchical groups with 50 A *cgroup* associates a set of tasks with a set of parameters for one 54 facilities provided by cgroups to treat groups of tasks in 67 cgroups. Each hierarchy is a partition of all tasks in the system. 81 tasks in each cgroup. 100 the division of tasks into cgroups is distinctly different for 102 hierarchy to be a natural division of tasks, without having to handle 103 complex combinations of tasks that would be present if several 114 tasks etc. The resource planning for this server could be along the 123 In addition (system tasks) are attached to topcpuset (so [all …]
|
D | cpusets.rst | 44 Nodes to a set of tasks. In this document "Memory Node" refers to 47 Cpusets constrain the CPU and Memory placement of tasks to only 82 the available CPU and Memory resources amongst the requesting tasks. 139 - You can list all the tasks (by pid) attached to any cpuset. 148 - in sched.c migrate_live_tasks(), to keep migrating tasks within 184 - cpuset.sched_relax_domain_level: the searching range when migrating tasks 192 CPUs and Memory Nodes, and attached tasks, are modified by writing 200 on a system into related sets of tasks such that each set is constrained 206 the detailed placement done on individual tasks and memory regions 264 of the rate that the tasks in a cpuset are attempting to free up in [all …]
|
D | memcg_test.rst | 188 /bin/echo $pid >$2/tasks 2>/dev/null 195 G1_TASK=`cat ${G1}/tasks` 196 G2_TASK=`cat ${G2}/tasks` 259 # echo 0 > /cgroup/test/tasks 265 # move all tasks in /cgroup/test to /cgroup 275 Out-of-memory caused by memcg's limit will kill tasks under 279 In this case, panic_on_oom shouldn't be invoked and tasks 306 #echo $$ >/cgroup/A/tasks 314 #echo "pid of the program running in group A" >/cgroup/B/tasks 335 # echo $$ >/cgroup/A/tasks
|
/Linux-v6.1/Documentation/admin-guide/hw-vuln/ |
D | core-scheduling.rst | 6 Core scheduling support allows userspace to define groups of tasks that can 8 group of tasks don't trust another), or for performance usecases (some 20 attacks. It allows HT to be turned on safely by ensuring that only tasks in a 35 Using this feature, userspace defines groups of tasks that can be co-scheduled 37 tasks that are not in the same group never run simultaneously on a core, while 42 well as admission and removal of tasks from created groups:: 67 will be performed for all tasks in the task group of ``pid``. 77 Building hierarchies of tasks 87 Transferring a cookie between the current and other tasks is possible using 91 scheduling group and share it with already running tasks. [all …]
|
/Linux-v6.1/Documentation/scheduler/ |
D | sched-design-CFS.rst | 19 1/nr_running speed. For example: if there are 2 tasks running, then it runs 26 is its actual runtime normalized to the total number of running tasks. 37 Small detail: on "ideal" hardware, at any time all tasks would have the same 38 p->se.vruntime value --- i.e., tasks would execute simultaneously and no task 44 up CPU time between runnable tasks as close to "ideal multitasking hardware" as 62 increasing value tracking the smallest vruntime among all tasks in the 67 The total number of running tasks in the runqueue is accounted through the 68 rq->cfs.load value, which is the sum of the weights of the tasks queued on the 71 CFS maintains a time-ordered rbtree, where all runnable tasks are sorted by the 73 As the system progresses forwards, the executed tasks are put into the tree [all …]
|
D | sched-deadline.rst | 43 that makes it possible to isolate the behavior of tasks between each other. 53 "deadline", to schedule tasks. A SCHED_DEADLINE task should receive 65 Summing up, the CBS[2,3] algorithm assigns scheduling deadlines to tasks so 67 interference between different tasks (bandwidth isolation), while the EDF[1] 69 to be executed next. Thanks to this feature, tasks that do not strictly comply 74 tasks in the following way: 128 Bandwidth reclaiming for deadline tasks is based on the GRUB (Greedy 132 The following diagram illustrates the state names for tasks handled by GRUB:: 201 tasks in active state (i.e., ActiveContending or ActiveNonContending); 203 - Total bandwidth (this_bw): this is the sum of all tasks "belonging" to the [all …]
|
D | sched-rt-group.rst | 14 2.3 Basis for grouping tasks 44 multiple groups of realtime tasks, each group must be assigned a fixed portion 57 tasks (SCHED_OTHER). Any allocated run time not used will also be picked up by 72 The remaining CPU time will be used for user input and other tasks. Because 73 realtime tasks have explicitly allocated the CPU time they need to perform 74 their tasks, buffer underruns in the graphics or audio can be eliminated. 110 SCHED_OTHER (non-RT tasks). These defaults were chosen so that a run-away 111 realtime tasks will not lock up the machine but leave a little time to recover 120 bandwidth to the group before it will accept realtime tasks. Therefore you will 121 not be able to run realtime tasks as any user other than root until you have [all …]
|
D | schedutil.rst | 15 individual tasks to task-group slices to CPU runqueues. As the basis for this 28 is key, since it gives the ability to recompose the averages when tasks move 31 Note that blocked tasks still contribute to the aggregates (task-group slices 96 Because periodic tasks have their averages decayed while they sleep, even 105 A further runqueue wide sum (of runnable tasks) is maintained of: 116 the runqueue keeps an max aggregate of these clamps for all running tasks. 148 XXX: deadline tasks (Sporadic Task Model) allows us to calculate a hard f_min 166 suppose we have a CPU saturated with 4 tasks, then when we migrate a task
|
/Linux-v6.1/samples/bpf/ |
D | tracex2_user.c | 85 static struct task tasks[1024]; in print_hist() local 93 if (memcmp(&tasks[i], &next_key, SIZE) == 0) in print_hist() 96 memcpy(&tasks[task_cnt++], &next_key, SIZE); in print_hist() 102 (__u32) tasks[i].pid_tgid, in print_hist() 103 tasks[i].comm, in print_hist() 104 (__u32) tasks[i].uid_gid); in print_hist() 105 print_hist_for_pid(fd, &tasks[i]); in print_hist()
|
D | map_perf_test_user.c | 94 static int pre_test_lru_hash_lookup(int tasks) in pre_test_lru_hash_lookup() argument 295 typedef int (*pre_test_func)(int tasks); 315 static int pre_test(int tasks) in pre_test() argument 321 int ret = pre_test_funcs[i](tasks); in pre_test() 346 static void run_perf_test(int tasks) in run_perf_test() argument 348 pid_t pid[tasks]; in run_perf_test() 351 assert(!pre_test(tasks)); in run_perf_test() 353 for (i = 0; i < tasks; i++) { in run_perf_test() 363 for (i = 0; i < tasks; i++) { in run_perf_test()
|
D | test_overhead_user.c | 98 static void run_perf_test(int tasks, int flags) in run_perf_test() argument 100 pid_t pid[tasks]; in run_perf_test() 103 for (i = 0; i < tasks; i++) { in run_perf_test() 113 for (i = 0; i < tasks; i++) { in run_perf_test()
|
/Linux-v6.1/Documentation/power/ |
D | freezing-of-tasks.rst | 2 Freezing of tasks 7 I. What is the freezing of tasks? 10 The freezing of tasks is a mechanism by which user space processes and some 18 and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have 30 All freezable tasks must react to that by calling try_to_freeze(), which 62 initiated a freezing operation, the freezing of tasks will fail and the entire 69 order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that 73 Rationale behind the functions dealing with freezing and thawing of tasks 77 - freezes only userspace tasks 80 - freezes all tasks (including kernel threads) because we can't freeze [all …]
|
/Linux-v6.1/drivers/gpu/drm/ |
D | drm_flip_work.c | 117 struct list_head tasks; in flip_worker() local 123 INIT_LIST_HEAD(&tasks); in flip_worker() 125 list_splice_tail(&work->commited, &tasks); in flip_worker() 129 if (list_empty(&tasks)) in flip_worker() 132 list_for_each_entry_safe(task, tmp, &tasks, node) { in flip_worker()
|
/Linux-v6.1/tools/perf/scripts/python/ |
D | sched-migration.py | 100 def __init__(self, tasks = [0], event = RunqueueEventUnknown()): argument 101 self.tasks = tuple(tasks) 107 if taskState(prev_state) == "R" and next in self.tasks \ 108 and prev in self.tasks: 114 next_tasks = list(self.tasks[:]) 115 if prev in self.tasks: 127 if old not in self.tasks: 129 next_tasks = [task for task in self.tasks if task != old] 134 if new in self.tasks: 137 next_tasks = self.tasks[:] + tuple([new]) [all …]
|
/Linux-v6.1/kernel/sched/ |
D | psi.c | 216 static bool test_state(unsigned int *tasks, enum psi_states state, bool oncpu) in test_state() argument 220 return unlikely(tasks[NR_IOWAIT]); in test_state() 222 return unlikely(tasks[NR_IOWAIT] && !tasks[NR_RUNNING]); in test_state() 224 return unlikely(tasks[NR_MEMSTALL]); in test_state() 226 return unlikely(tasks[NR_MEMSTALL] && in test_state() 227 tasks[NR_RUNNING] == tasks[NR_MEMSTALL_RUNNING]); in test_state() 229 return unlikely(tasks[NR_RUNNING] > oncpu); in test_state() 231 return unlikely(tasks[NR_RUNNING] && !oncpu); in test_state() 233 return tasks[NR_IOWAIT] || tasks[NR_MEMSTALL] || in test_state() 234 tasks[NR_RUNNING]; in test_state() [all …]
|
/Linux-v6.1/tools/perf/Documentation/ |
D | perf-timechart.txt | 48 --tasks-only:: 60 Print task info for at least given number of tasks. 65 Highlight tasks (using different color) that run more than given 66 duration or tasks with given name. If number is given it's interpreted 89 --tasks-only:: 90 Record only tasks-related events 114 then generate timechart and highlight 'gcc' tasks:
|
/Linux-v6.1/Documentation/admin-guide/kdump/ |
D | gdbmacros.txt | 17 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) 20 set $next_t=(((char *)($init_t->tasks).next) - $tasks_off) 51 set $next_t=(char *)($next_t->tasks.next) - $tasks_off 83 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) 86 set $next_t=(((char *)($init_t->tasks).next) - $tasks_off) 97 set $next_t=(char *)($next_t->tasks.next) - $tasks_off 106 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) 109 set $next_t=(((char *)($init_t->tasks).next) - $tasks_off) 127 set $next_t=(char *)($next_t->tasks.next) - $tasks_off 139 set $tasks_off=((size_t)&((struct task_struct *)0)->tasks) [all …]
|
/Linux-v6.1/Documentation/x86/x86_64/ |
D | fake-numa-for-cpusets.rst | 14 assign them to cpusets and their attached tasks. This is a way of limiting the 15 amount of system memory that are available to a certain class of tasks. 56 You can now assign tasks to these cpusets to limit the memory resources 59 [root@xroads /exampleset/ddset]# echo $$ > tasks 75 This allows for coarse memory management for the tasks you assign to particular 77 interesting combinations of use-cases for various classes of tasks for your
|
/Linux-v6.1/Documentation/livepatch/ |
D | livepatch.rst | 85 transition state where tasks are converging to the patched state. 87 sequence occurs when a patch is disabled, except the tasks converge from 91 interrupts. The same is true for forked tasks: the child inherits the 95 safe to patch tasks: 98 tasks. If no affected functions are on the stack of a given task, 100 the tasks on the first try. Otherwise it'll keep trying 108 a) Patching I/O-bound user tasks which are sleeping on an affected 111 b) Patching CPU-bound user tasks. If the task is highly CPU-bound 115 3. For idle "swapper" tasks, since they don't ever exit the kernel, they 122 the second approach. It's highly likely that some tasks may still be [all …]
|
/Linux-v6.1/Documentation/locking/ |
D | futex-requeue-pi.rst | 5 Requeueing of tasks from a non-PI futex to a PI futex requires 17 pthread_cond_broadcast() must resort to waking all the tasks waiting 47 Once pthread_cond_broadcast() requeues the tasks, the cond->mutex 54 be able to requeue tasks to PI futexes. This support implies that 113 possibly wake the waiting tasks. Internally, this system call is 118 nr_wake+nr_requeue tasks to the PI futex, calling 126 requeue up to nr_wake + nr_requeue tasks. It will wake only as many 127 tasks as it can acquire the lock for, which in the majority of cases
|
/Linux-v6.1/drivers/misc/bcm-vk/ |
D | Kconfig | 11 multiple specific offload processing tasks in parallel. 12 Such offload tasks assist in such operations as video 13 transcoding, compression, and crypto tasks.
|
/Linux-v6.1/tools/testing/selftests/resctrl/ |
D | resctrlfs.c | 399 static int write_pid_to_tasks(char *tasks, pid_t pid) in write_pid_to_tasks() argument 403 fp = fopen(tasks, "w"); in write_pid_to_tasks() 439 char tasks[1024]; in write_bm_pid_to_resctrl() local 451 sprintf(tasks, "%s/tasks", controlgroup); in write_bm_pid_to_resctrl() 452 ret = write_pid_to_tasks(tasks, bm_pid); in write_bm_pid_to_resctrl() 466 sprintf(tasks, "%s/mon_groups/%s/tasks", in write_bm_pid_to_resctrl() 468 ret = write_pid_to_tasks(tasks, bm_pid); in write_bm_pid_to_resctrl()
|
/Linux-v6.1/tools/testing/selftests/bpf/progs/ |
D | bpf_iter_task_btf.c | 11 long tasks = 0; variable 33 tasks++; in dump_task_struct()
|