On 2020/3/23 9:15, haoxin wrote:
您好: 请问目前欧拉这块有关于mpam功能验证的测试方法或者手册吗?
有一个简单的操作说明,你可以针对场景做一下测试。有问题可以反馈。
----- 1 背景 MPAM 特性是 ARM v8.4 引入的 Cache QoS, 和 内存带宽 QoS 特性. 目前业界与之最接近的是 intel 的 RDT 特性. Intel RDT 在 Linux 内核中的使用接口是 resctrl。这是一个基于 kernfs 实现的操作接口。为支持 MPAM 特性, 我们的目标也是实现类似 intel rdt 的 resctrl 用户接口。 社区当前还没有 ARM64 resctrl 接口的实现(arm公司在做, 还没有发开源社区).
2 Quick Start Hi620 2P 为例, 其基本情况:
2.1 linux kernel 使能 mpam 特性 openEuler 中 mpam 是 preview 特性, 当前版本暂没有商用, 默认没有使能. 如果想在鲲鹏920 2P 板子上验证 mpam 特性, 需要在启动参数中加 mpam 使能. openEuler 上使能 mpam, 需要在 /boot/grub2/grub.cfg 或 /boot/efi/EFI/euleros/grub.cfg 中添加 mpam 启动参数.
2.2 挂载 resctrl 系统启动后, 需要手动 mount resctrl 才能使用.
mount -t resctrl resctrl /sys/fs/resctrl cd /sys/fs/resctrl
2.3 配置和使用资源组 2.3.1 为 L3 Cache 的 PARTID 1 分配 4 个 Cache way # 每个目录表示对于的 L3T cd /sys/fs/resctrl
# 先选择某个 PARTID, 在为其设定 mask, mask 就是对应的 cache way # 这里选 partid=1, mask=f, 即为 partid 1 分了 0-3 计4条way (共15条way) mkdir p1 cd p1 echo "L3:0=f;1=f;2=f;3=f" > schemata cat schemata # 查看设置情况 cd .. # 返回上次目录
# 更多的例子 # partid = 2, N0 (way 5,6), N1 (way 5-8), N2 (way 5,6), N3 (way 5-15) # mask 16进制 mkdir p2 cd p2 echo "L3:0=30;1=f0;2=30;3=f0" > schemata cat schemata # 查看设置情况 cd .. # 返回上次目录
Cache 和 内存带宽的 partid 数量不同, 但是 resctrl 接口当前又是Cache和partid同时操作的, 所以当前实现时已最小的为准;
2.3.2 为 Cache/memory bandwidth 设置 monitor, 并观察期使用情况 由于 monitor 数量较少, 所以在创建分组的时候没有默认开启, 需要手动开启.
# p1 分组已存在, 开启 monitor echo 1 > /sys/fs/resctrl/p1/ctrlmon # 观察该组资源的使用情况 # L3 Cache 的单位是 Bytes, 表明当前 Cache 被占用这么多; # Memory Bandwidth 单位是MB/s (架构要求的是 MB/s, 鲲鹏920 看具体实现) grep . /sys/fs/resctrl/p1/mon_data/*
2.3.3 为进程/线程分配分组(让进程/线程只使用某个 part 的资源) # task 19 将使用 partid 1 限定的资源 (pmg 在监控的时候用, pmg 和 partid 都匹配, 才进行统计监控使用情况) # 将 task 19 move 到 p1 资源组中 # 新创建的子进程, 将继承父进程的 partid 和 pmg 信息 # move 进程时, 已创建的子进程不影响 echo 19 > /sys/fs/resctrl/p1/tasks
# 设置当前 shell 使用那个组的Cache资源 ($$ 表示当前 shell 的 PID) echo $$ > /sys/fs/resctrl/p1/tasks
# 查看 task 的设置情况 cat /sys/fs/resctrl/p1/tasks
2.3.4 为 cpu 分配分组(让指定的 cpu 只使用某个 part 的资源) 即, 该 cpu 上发出的所有请求都是要改资源组限定的资源(cache, memory bandwidth)
# task 1 将使用 partid 2 限定的资源 (pmg 在监控的时候用, pmg 和 partid 都匹配, 才进行统计监控使用情况) # 将 cpu 1 move 到 p2 资源组中 echo 1 > /sys/fs/resctrl/p2/cpus_list
# 查看 task 的设置情况 cat /sys/fs/resctrl/p2/cpus # 掩码方式显示 cat /sys/fs/resctrl/p2/cpus_list # 列表方式显示
2.4 内存带宽资源划分
2.4.1 为 PART 1 设置内存带宽的上限 # PART 1, 最多使用约 50% 的带宽; # 0,1,2,3 分别表示 4 个 numa node # 带宽按照百分比进行设置, 最小粒度是 5% 对齐.
echo "MB:0=50;1=50;2=50;3=50" > /sys/fs/resctrl/p1/schemata
2.4.3 分配进程(pid)到资源分组 挂载 resctrl cache 资源划分 设置 monitor 起测试程序 (假设 lat_mem_rd 程序在 /root 目录下面, 其他随便什么程序都一样) # 挂载 mpamctrl mount -t resctrl resctrl /sys/fs/resctrl cd /sys/fs/resctrl
# 使用 part 1, 为其分配 4 个way (4 个 node 采用相同的设置) # partid=1, mask=f mkdir p1 echo "L3:0=f;1=f;2=f;3=f" > schemata
# 使用 monitor 1 来监控 part 1 的 cache 使用情况 # monitor=1, pmg=1, partid=1 echo 1 > p1/ctrlmon
# 设置当前 shell 进程使用 partid 1 (task 使用哪个 part, 在子进程创建时会继承父进程的) # 两个 $$ 代表当前 shell 的pid echo $$ > p1/tasks
# 在后台跑测试程序, 测试结果记录到 result.log 中 cd /root /root/lat_mem_rd -P 1 -N 1 512M 64 > result.log 2 > &1 &
# lat_mem_rd 测试完成后查看结果. 如果想再测 8 way 的情况, 则只需改 CPBM 的 mask 即可:
echo "L3:0=ff;1=ff;2=ff;3=ff" > schemata 测试过程中如果想观察 Cache 的使用情况
grep . /sys/fs/resctrl/p1/mon_data/L3*
3.2 限制内存带宽的例子 步骤:
挂载 resctrl 限制资源划分 设置 monitor 起测试程序 mount -t resctrl resctrl /sys/fs/resctrl cd /sys/fs/resctrl
# 0/100 表示不限制 # 其他数值表示最大带宽设置的百分比(硬件限制的粒度是 1/64, 软件上近似对应成百分比, 最小按5%对齐). mkdir p1 echo "MB:0=30;1=30;2=30;3=30" > p1/schemata echo 1 > p1/ctrlmon
# 设置当前 shell 进程使用 partid 1 (task 使用哪个 part, 在子进程创建时会继承父进程的) # 两个 $$ 代表当前 shell 的pid echo $$ > /sys/fs/resctrl/p1/tasks # 在后台跑测试程序, 测试结果记录到 result.log 中 cd /root /root/bw_mem -P 1 -N 1 512M rd > result.log 2 > &1 &
# 观察monitor情况 cd /sys/fs/resctrl # monitor=1 grep . /sys/fs/resctrl/p1/mon_data/MB*
此外目前resctrl挂载后和intel rdt进行了对比,发现很多文件都不存在,例如 请问是代码还未完成还是做了简化?
例如我在info目录下有L3_MON目录,按照intel rdt的处理,应该有下面一些子文件:但是在mpam下面就没有
“num_rmids”: The number of RMIDs available. This is the upper bound for how many “CTRL_MON” + “MON” groups can be created. “mon_features”: Lists the monitoring events if monitoring is enabled for the resource. “max_threshold_occupancy”: Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancy counter can be considered for re-use.