| /linux/Documentation/admin-guide/cgroup-v1/ |
| H A 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 …]
|
| H A 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.
|
| H A 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.
102 the division of tasks into cgroups is distinctly different for
104 hierarchy to be a natural division of tasks, without having to handle
105 complex combinations of tasks that would be present if several
116 tasks etc. The resource planning for this server could be along the
125 In addition (system tasks) are attached to topcpuset (so
[all …]
|
| /linux/Documentation/admin-guide/hw-vuln/ |
| H A 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/Documentation/power/ |
| H A 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
19 The tasks that have PF_NOFREEZE unset (all user space tasks and some kernel
31 wakes up all the kernel threads. All freezable tasks must react to that by
38 tasks are generally frozen before kernel threads.
72 has initiated a freezing operation, the freezing of tasks will fail and the
79 order to wake up each frozen task. Then, the tasks that have been frozen leave
83 Rationale behind the functions dealing with freezing and thawing of tasks
87 - freezes only userspace tasks
[all …]
|
| /linux/Documentation/scheduler/ |
| H A D | sched-util-clamp.rst | 12 of tasks. It was introduced in v5.3 release. The CGroup support was merged in
16 performance requirements and restrictions of the tasks, thus it helps the
35 One can tell the system (scheduler) that some tasks require a minimum
37 can tell the system that some tasks should be restricted from consuming too
45 dropped. It can also dynamically 'prime' up these tasks if it knows in the
56 Another example is in Android where tasks are classified as background,
58 resources background tasks are consuming by capping the performance point they
59 can run at. This constraint helps reserve resources for important tasks, like
63 background tasks to stay on the little cores which will ensure that:
65 1. The big cores are free to run top-app tasks immediately. top-app
[all …]
|
| H A D | sched-rt-group.rst | 14 2.3 Basis for grouping tasks
44 multiple groups of real-time 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 real-time tasks have explicitly allocated the CPU time they need to perform
74 their tasks, buffer underruns in the graphics or audio can be eliminated.
95 period_us for the real-time tasks. Even without CONFIG_RT_GROUP_SCHED enabled,
112 SCHED_OTHER (non-RT tasks). These defaults were chosen so that a run-away
113 real-time tasks will not lock up the machine but leave a little time to recover
122 bandwidth to the group before it will accept real-time tasks. Therefore you will
[all …]
|
| H A 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
104 A further runqueue wide sum (of runnable tasks) is maintained of:
115 the runqueue keeps an max aggregate of these clamps for all running tasks.
147 XXX: deadline tasks (Sporadic Task Model) allows us to calculate a hard f_min
165 suppose we have a CPU saturated with 4 tasks, then when we migrate a task
|
| /linux/kernel/rcu/ |
| H A D | tasks.h | 24 * struct rcu_tasks_percpu - Per-CPU component of definition for a Tasks-RCU-like mechanism.
34 * @rtp_blkd_tasks: List of tasks blocked as readers.
35 * @rtp_exit_list: List of tasks in the latter portion of do_exit().
58 * struct rcu_tasks - Definition for a Tasks-RCU-like mechanism.
193 /* RCU tasks grace-period state for debugging. */
250 // Tasks RCU. Do not enqueue callbacks before this function is invoked. in cblist_init_generic()
344 // Enqueue a callback for the specified flavor of Tasks RCU. in call_rcu_tasks_generic()
420 // Wait for all in-flight callbacks for the specified RCU Tasks flavor. in rcu_barrier_tasks_generic()
631 // RCU-tasks kthread that detects grace periods and invokes callbacks. in rcu_tasks_kthread()
651 * one RCU-tasks grac
[all...] |
| /linux/kernel/livepatch/ |
| H A D | transition.c | 51 * "straggler" tasks which failed to transition in the first attempt.
67 * tasks even in userspace and idle.
108 * All tasks have transitioned to KLP_TRANSITION_UNPATCHED so we can now in klp_complete_transition()
325 * on other methods (e.g., switching tasks at kernel exit). in klp_try_switch_task()
405 * Sends a fake signal to all non-kthread tasks with TIF_PATCH_PENDING set.
413 pr_notice("signaling remaining tasks\n"); in klp_send_signals()
434 * Send fake signal to all non-kthread tasks which are in klp_send_signals()
444 * Try to switch all remaining tasks to the target patch state by walking the
445 * stacks of sleeping tasks and looking for any to-be-patched or
449 * If any tasks are still stuck in the initial patch state, schedule a retry.
[all …]
|
| /linux/Documentation/RCU/ |
| H A D | stallwarn.rst | 118 The RCU, RCU-sched, RCU-tasks, and RCU-tasks-trace implementations have
209 This boot/sysfs parameter controls the RCU-tasks and
210 RCU-tasks-trace stall warning intervals. A value of zero or less
211 suppresses RCU-tasks stall warnings. A positive value sets the
212 stall-warning interval in seconds. An RCU-tasks stall warning
215 INFO: rcu_tasks detected stalls on tasks:
218 task stalling the current RCU-tasks grace period.
220 An RCU-tasks-trace stall warning starts (and continues) similarly:
222 INFO: rcu_tasks_trace detected stalls on tasks
228 For non-RCU-tasks flavors of RCU, when a CPU detects that some other
[all …]
|
| /linux/tools/perf/scripts/python/ |
| H A 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/tools/testing/selftests/futex/include/ |
| H A D | futextest.h | 84 * futex_wake() - wake one or more tasks blocked on uaddr
85 * @nr_wake: wake up to this many tasks
106 * futex_wake_bitset() - wake one or more tasks blocked on uaddr with bitset
149 * @nr_wake: wake up to this many tasks
150 * @nr_requeue: requeue up to this many tasks
164 * futex_cmp_requeue() - requeue tasks from uaddr to uaddr2
165 * @nr_wake: wake up to this many tasks
166 * @nr_requeue: requeue up to this many tasks
193 * futex_cmp_requeue_pi() - requeue tasks from uaddr to uaddr2 (PI aware)
196 * @nr_wake: wake up to this many tasks
[all …]
|
| /linux/kernel/sched/ |
| H A D | psi.c | 11 * When CPU, memory and IO are contended, tasks experience delays that
30 * In the SOME state of a given resource, one or more tasks are
32 * perform work, but the CPU may still be executing other tasks.
34 * In the FULL state of a given resource, all non-idle tasks are
48 * FULL means all non-idle tasks in the cgroup are delayed on the CPU
62 * The more tasks and available CPUs there are, the more work can be
65 * tasks and CPUs.
67 * Consider a scenario where 257 number crunching tasks are trying to
75 * Conversely, consider a scenario of 4 tasks and 4 CPUs where at any
76 * given time *one* of the tasks is delayed due to a lack of memory.
[all …]
|
| /linux/include/linux/ |
| H A D | psi_types.h | 19 * For IO and CPU stalls the presence of running/oncpu tasks
54 * SOME: Stalled tasks & working tasks
55 * FULL: Stalled tasks & no working tasks
90 /* States of the tasks belonging to this group */
91 unsigned int tasks[NR_PSI_TASK_COUNTS]; member
93 /* Aggregate pressure state derived from the tasks */
|
| /linux/Documentation/locking/ |
| H A 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/tools/perf/Documentation/ |
| H A 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/Documentation/admin-guide/kdump/ |
| H A 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/tools/perf/bench/ |
| H A D | futex.h | 73 * futex_wake() - wake one or more tasks blocked on uaddr
74 * @nr_wake: wake up to this many tasks
101 * futex_cmp_requeue() - requeue tasks from uaddr to uaddr2
102 * @nr_wake: wake up to this many tasks
103 * @nr_requeue: requeue up to this many tasks
130 * futex_cmp_requeue_pi() - requeue tasks from uaddr to uaddr2
133 * @nr_requeue: requeue up to this many tasks
|
| /linux/include/uapi/linux/ |
| H A D | cgroupstats.h | 31 __u64 nr_sleeping; /* Number of tasks sleeping */
32 __u64 nr_running; /* Number of tasks running */
33 __u64 nr_stopped; /* Number of tasks in stopped state */
34 __u64 nr_uninterruptible; /* Number of tasks in uninterruptible */
36 __u64 nr_io_wait; /* Number of tasks waiting on IO */
|
| /linux/Documentation/arch/x86/x86_64/ |
| H A 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/tools/testing/selftests/bpf/benchs/ |
| H A D | bench_local_storage_rcu_tasks_trace.c | 236 /* local-storage-tasks-trace: Benchmark performance of BPF local_storage's use
237 * of RCU Tasks-Trace.
239 * Stress RCU Tasks Trace by forking many tasks, all of which do no work aside
241 * The number of forked tasks is configurable.
244 * thousands of tasks on the system should result in RCU Tasks-Trace having to
255 .name = "local-storage-tasks-trace",
|
| /linux/kernel/power/ |
| H A D | process.c | 31 "remaining freezable tasks"; in try_to_freeze_tasks()
75 * We need to retry, but first give the freezing tasks some in try_to_freeze_tasks()
90 "(%d tasks refusing to freeze, wq_busy=%d):\n", what, in try_to_freeze_tasks()
146 * killable tasks. There is no guarantee oom victims will in freeze_processes()
162 * (if any) before thawing the userspace tasks. So, it is the responsibility
163 * of the caller to thaw the userspace tasks, when the time is right.
192 pr_info("Restarting tasks ... "); in thaw_processes()
|
| /linux/samples/bpf/ |
| H A D | tracex2_user.c | |
| /linux/Documentation/arch/x86/ |
| H A D | resctrl.rst | 159 Indicator on Intel systems of how tasks running on threads
282 after mounting, owns all the tasks and cpus in the system and can make
292 directories can be created to monitor subsets of tasks in the CTRL_MON
296 Removing a directory will move all tasks and cpus owned by the group it
302 without impacting its monitoring data or assigned tasks. This operation
309 "tasks":
310 Reading this file shows the list of all tasks that belong to
312 group. Multiple tasks can be added by separating the task ids
313 with commas. Tasks will be assigned sequentially. Multiple
316 already added tasks before the failure will remain in the group.
[all …]
|