Lines Matching full:group
104 "shareable_bits" but no resource group will
110 well as a resource group's allocation.
116 one resource group. No sharing allowed.
187 system. The default group is the root directory which, immediately
199 group that is their ancestor. These are called "MON" groups in the rest
202 Removing a directory will move all tasks and cpus owned by the group it
210 this group. Writing a task id to the file will add a task to the
211 group. If the group is a CTRL_MON group the task is removed from
212 whichever previous CTRL_MON group owned the task and also from
213 any MON group that owned the task. If the group is a MON group,
215 group. The task is removed from any previous MON group.
220 this group. Writing a mask to this file will add and remove
221 CPUs to/from this group. As with the tasks file a hierarchy is
223 parent CTRL_MON group.
224 When the resource group is in pseudo-locked mode this file will
236 A list of all the resources available to this group.
245 The "mode" of the resource group dictates the sharing of its
246 allocations. A "shareable" resource group allows sharing of its
247 allocations while an "exclusive" resource group does not. A
250 pseudo-locked region's schemata to the resource group's "schemata"
261 "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these
263 all tasks in the group. In CTRL_MON groups these files provide
264 the sum for all tasks in the CTRL_MON group and all tasks in
273 1) If the task is a member of a non-default group, then the schemata
274 for that group is used.
276 2) Else if the task belongs to the default group, but is running on a
277 CPU that is assigned to some specific group, then the schemata for the
278 CPU's group is used.
280 3) Otherwise the schemata for the default group is used.
284 1) If a task is a member of a MON group, or non-default CTRL_MON group
285 then RDT events for the task will be reported in that group.
287 2) If a task is a member of the default CTRL_MON group, but is running
288 on a CPU that is assigned to some specific group, then the RDT events
289 for the task will be reported in that group.
292 "mon_data" group.
297 When moving a task from one group to another you should remember that
299 a task in a monitor group showing 3 MB of cache occupancy. If you move
300 to a new group and immediately check the occupancy of the old and new
301 groups you will likely see that the old group is still showing 3 MB and
302 the new group zero. When the task accesses locations still in cache from
304 you will likely see the occupancy in the old group go down as cache lines
305 are evicted and re-used while the occupancy in the new group rises as
307 membership in the new group.
309 The same applies to cache allocation control. Moving a task to a group
314 to identify a control group and a monitoring group respectively. Each of
315 the resource groups are mapped to these IDs based on the kind of group. The
318 and creation of "MON" group may fail if we run out of RMIDs.
548 1) Create a new resource group by creating a new directory in /sys/fs/resctrl.
549 2) Change the new resource group's mode to "pseudo-locksetup" by writing
557 group will exist in /dev/pseudo_lock. This character device can be mmap()'ed
679 The default resource group is unmodified, so we have access to all parts
682 Tasks that are under the control of group "p0" may only allocate from the
684 Tasks in group "p1" use the "lower" 50% of cache on both sockets.
686 Similarly, tasks that are under the control of group "p0" may use a
688 Tasks in group "p1" may also use 50% memory b/w on both sockets.
691 b/w that the group may be able to use and the system admin can configure
717 First we reset the schemata for the default group so that the "upper"
723 Next we make a resource group for our first real time task and give
730 Finally we move our first real time task into this resource group. We
773 First we reset the schemata for the default group so that the "upper"
779 Next we make a resource group for our real time cores and give it access
787 Finally we move core 4-7 over to the new group and make sure that the
798 mode allowing sharing of their cache allocations. If one resource group
799 configures a cache allocation then nothing prevents another resource group
802 In this example a new exclusive resource group will be created on a L2 CAT
804 capacity bitmask. The new exclusive resource group will be configured to use
811 First, we observe that the default group is configured to allocate to all L2
817 We could attempt to create the new resource group at this point, but it will
818 fail because of the overlap with the schemata of the default group::
829 To ensure that there is no overlap with another resource group the default
830 resource group's schemata has to change, making it possible for the new
831 resource group to become exclusive.
842 A new resource group will on creation not overlap with an exclusive resource
843 group::
857 A resource group cannot be forced to overlap with an exclusive resource group::
862 overlaps with exclusive group
876 removed from the default resource group's schemata::
884 Create a new resource group that will be associated with the pseudo-locked
892 On success the resource group's mode will change to pseudo-locked, the
1090 group or CTRL_MON group.
1093 Example 1 (Monitor CTRL_MON group and subset of tasks in CTRL_MON group)
1106 The default resource group is unmodified, so we have access to all parts
1109 Tasks that are under the control of group "p0" may only allocate from the
1111 Tasks in group "p1" use the "lower" 50% of cache on both sockets.
1113 Create monitor groups and assign a subset of tasks to each monitor group.
1131 The parent ctrl_mon group shows the aggregated data.
1145 An RMID is allocated to the group once its created and hence the <cmd>
1162 But user can create different MON groups within the root group thereby