Lines Matching refs:group

111 			      "shareable_bits" but no resource group will
117 well as a resource group's allocation.
123 one resource group. No sharing allowed.
271 system. The default group is the root directory which, immediately
283 group that is their ancestor. These are called "MON" groups in the rest
286 Removing a directory will move all tasks and cpus owned by the group it
290 Moving MON group directories to a new parent CTRL_MON group is supported
291 for the purpose of changing the resource allocations of a MON group
295 MON group.
301 this group. Writing a task id to the file will add a task to the
302 group. If the group is a CTRL_MON group the task is removed from
303 whichever previous CTRL_MON group owned the task and also from
304 any MON group that owned the task. If the group is a MON group,
306 group. The task is removed from any previous MON group.
311 this group. Writing a mask to this file will add and remove
312 CPUs to/from this group. As with the tasks file a hierarchy is
314 parent CTRL_MON group.
315 When the resource group is in pseudo-locked mode this file will
327 A list of all the resources available to this group.
336 The "mode" of the resource group dictates the sharing of its
337 allocations. A "shareable" resource group allows sharing of its
338 allocations while an "exclusive" resource group does not. A
341 pseudo-locked region's schemata to the resource group's "schemata"
352 "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these
354 all tasks in the group. In CTRL_MON groups these files provide
355 the sum for all tasks in the CTRL_MON group and all tasks in
364 1) If the task is a member of a non-default group, then the schemata
365 for that group is used.
367 2) Else if the task belongs to the default group, but is running on a
368 CPU that is assigned to some specific group, then the schemata for the
369 CPU's group is used.
371 3) Otherwise the schemata for the default group is used.
375 1) If a task is a member of a MON group, or non-default CTRL_MON group
376 then RDT events for the task will be reported in that group.
378 2) If a task is a member of the default CTRL_MON group, but is running
379 on a CPU that is assigned to some specific group, then the RDT events
380 for the task will be reported in that group.
383 "mon_data" group.
388 When moving a task from one group to another you should remember that
390 a task in a monitor group showing 3 MB of cache occupancy. If you move
391 to a new group and immediately check the occupancy of the old and new
392 groups you will likely see that the old group is still showing 3 MB and
393 the new group zero. When the task accesses locations still in cache from
395 you will likely see the occupancy in the old group go down as cache lines
396 are evicted and re-used while the occupancy in the new group rises as
398 membership in the new group.
400 The same applies to cache allocation control. Moving a task to a group
405 to identify a control group and a monitoring group respectively. Each of
406 the resource groups are mapped to these IDs based on the kind of group. The
409 and creation of "MON" group may fail if we run out of RMIDs.
698 1) Create a new resource group by creating a new directory in /sys/fs/resctrl.
699 2) Change the new resource group's mode to "pseudo-locksetup" by writing
707 group will exist in /dev/pseudo_lock. This character device can be mmap()'ed
829 The default resource group is unmodified, so we have access to all parts
832 Tasks that are under the control of group "p0" may only allocate from the
834 Tasks in group "p1" use the "lower" 50% of cache on both sockets.
836 Similarly, tasks that are under the control of group "p0" may use a
838 Tasks in group "p1" may also use 50% memory b/w on both sockets.
841 b/w that the group may be able to use and the system admin can configure
867 First we reset the schemata for the default group so that the "upper"
873 Next we make a resource group for our first real time task and give
880 Finally we move our first real time task into this resource group. We
923 First we reset the schemata for the default group so that the "upper"
929 Next we make a resource group for our real time cores and give it access
937 Finally we move core 4-7 over to the new group and make sure that the
948 mode allowing sharing of their cache allocations. If one resource group
949 configures a cache allocation then nothing prevents another resource group
952 In this example a new exclusive resource group will be created on a L2 CAT
954 capacity bitmask. The new exclusive resource group will be configured to use
961 First, we observe that the default group is configured to allocate to all L2
967 We could attempt to create the new resource group at this point, but it will
968 fail because of the overlap with the schemata of the default group::
979 To ensure that there is no overlap with another resource group the default
980 resource group's schemata has to change, making it possible for the new
981 resource group to become exclusive.
992 A new resource group will on creation not overlap with an exclusive resource
993 group::
1007 A resource group cannot be forced to overlap with an exclusive resource group::
1012 overlaps with exclusive group
1026 removed from the default resource group's schemata::
1034 Create a new resource group that will be associated with the pseudo-locked
1042 On success the resource group's mode will change to pseudo-locked, the
1240 group or CTRL_MON group.
1243 Example 1 (Monitor CTRL_MON group and subset of tasks in CTRL_MON group)
1256 The default resource group is unmodified, so we have access to all parts
1259 Tasks that are under the control of group "p0" may only allocate from the
1261 Tasks in group "p1" use the "lower" 50% of cache on both sockets.
1263 Create monitor groups and assign a subset of tasks to each monitor group.
1281 The parent ctrl_mon group shows the aggregated data.
1295 An RMID is allocated to the group once its created and hence the <cmd>
1312 But user can create different MON groups within the root group thereby