Hi Michal, thanks for your reply.
The current 'mempolicy' is hierarchically independent. The default value
of the child is to inherit from the parent. The modification of the
child policy will not be restricted by the parent.
Of course, there are other options, such as the child's policy mode must
be the same as the parent's. node can be the subset of parent's, but the
interleave type will be complicated, that's why hierarchy independence
is used. It would be better if you have other suggestions?
Thanks.
On Sun 04-09-22 12:02:41, hezhongkun wrote:
From: Zhongkun He <hezhongkun.hzk@xxxxxxxxxxxxx>
Mempolicy is difficult to use because it is set in-process
via a system call. We want to make it easier to use mempolicy
in cpuset, and we can control low-priority cgroups to
allocate memory in specified nodes. So this patch want to
adds the mempolicy interface in cpuset.
The mempolicy priority of cpuset is lower than the task.
The order of getting the policy is:
1) vma mempolicy
2) task->mempolicy
3) cpuset->mempolicy
4) default policy.
cpuset's policy is owned by itself, but descendants will
get the default mempolicy from parent.
What is the hierarchical behavior of the policy? Say parent has a
stronger requirement (say bind) than a child (prefer)?
How to use the mempolicy interface:
echo prefer:2 > /sys/fs/cgroup/zz/cpuset.mems.policy
echo bind:1-3 > /sys/fs/cgroup/zz/cpuset.mems.policy
echo interleave:0,1,2,3 >/sys/fs/cgroup/zz/cpuset.mems.policy
Am I just confused or did you really mean to combine all these
together?
