- Kernel - mailweb.openeuler.org

[PATCH] apply to add a new mpam sig
by Xie XiuQi 08 Apr '20

08 Apr '20

MPAM is a new feature on Kunpeng platform, which is used to control LLC and memory bandwidth allocation and monitoring. SIG Mission and Scope: - enable mpam feature on Kunpeng Platform - develop supporting tools - assist the application in actual scenarios - improve MPAM according to the requirements of application scenarios - explore new application scenarios for MPAM - through more applications and tests, push the MPAM driver into the kernel upstream Signed-off-by: Xie XiuQi <xiexiuqi(a)huawei.com> --- repository/openeuler.yaml | 5 ++++ sig/sig-mpam/sig-mpam.md | 48 +++++++++++++++++++++++++++++++++++++ sig/sig-mpam/sig-mpam_cn.md | 29 ++++++++++++++++++++++ sig/sigs.yaml | 5 +++- 4 files changed, 86 insertions(+), 1 deletion(-) create mode 100644 sig/sig-mpam/sig-mpam.md create mode 100644 sig/sig-mpam/sig-mpam_cn.md diff --git a/repository/openeuler.yaml b/repository/openeuler.yaml index f91d628..23584c5 100644 --- a/repository/openeuler.yaml +++ b/repository/openeuler.yaml @@ -151,3 +151,8 @@ repositories: protected_branches: - master type: public +- name: mpam + description: "Memory System Resource Partitioning and Monitoring" + protected_branches: + - master + type: public diff --git a/sig/sig-mpam/sig-mpam.md b/sig/sig-mpam/sig-mpam.md new file mode 100644 index 0000000..743486f --- /dev/null +++ b/sig/sig-mpam/sig-mpam.md @@ -0,0 +1,48 @@ +# Application to create mpam SIG +English | [简体中文](./sig-template_cn.md) + +MPAM is a new feature on Kunpeng platform, which is used to control LLC +and memory bandwidth allocation and monitoring. + +## SIG Mission and Scope + +- enable mpam feature on Kunpeng Platform +- develop supporting tools +- assist the application in actual scenarios +- improve MPAM according to the requirements of application scenarios +- explore new application scenarios for MPAM +- through more applications and tests, push the MPAM driver into the kernel upstream + +### Deliverables + +- mpam document: https://gitee.com/openeuler/mpam +- mpam drivers (inlcuded in kernel tree): https://gitee.com/openeuler/kernel +- mpam supporting tools (todo) + +### Repositories and description managed by this SIG + + +### Cross-domain and external-oriented processes + +## Basic Information + +### Project Introduction + https: /gitee.com/openeuler/community/sig/sig-mpam/ + +``` +### Maintainers +- Xie XiuQi [@xiexiuqi](https://gitee.com/xiexiuqi) +- Wang Shaobo [@jentlestea](https://gitee.com/jentlestea) + +### Committers +- Xie XiuQi [@xiexiuqi](https://gitee.com/xiexiuqi) +- Wang Shaobo [@jentlestea](https://gitee.com/jentlestea) + +### Mailing list +- kernel(a)openeuler.org + +### IRC Channel +NA + +``` + diff --git a/sig/sig-mpam/sig-mpam_cn.md b/sig/sig-mpam/sig-mpam_cn.md new file mode 100644 index 0000000..6ffc41b --- /dev/null +++ b/sig/sig-mpam/sig-mpam_cn.md @@ -0,0 +1,29 @@ +# openEuler MPAM 兴趣小组 +[English](./sig-mpam.md) | 简体中文 + +MPAM(Memory Partitioning and Monitoring) 是鲲鹏920的新特性，用来控制 Cache, +内存带宽等资源的分配。混部业务场景下共享资源竞争可能会对业务性能造成很大干扰, +MPAM特性，针对LLC及访存带宽进行隔离和限制，可以减少业务间干扰，保障高优先级业务等。 + +## SIG组工作目标和范围 + +- 使能鲲鹏芯片的 MPAM 特性 +- 完善 MPAM 配套工具, 和文档 +- 推动和协助 MPAM 在实际场景中的应用和落地 +- 根据应用场景的诉求改进 MPAM +- 探索 MPAM 的新应用场景 +- 通过更多的应用和测试，推动MPAM驱动进入内核上游社区 + +### 该SIG管理的repository及描述 + +- 项目名称： + - mpam document：https://gitee.com/openeuler/mpam + - mpam 驱动在 kernel 仓库中：https://gitee.com/openeuler/kernel + - 将来会有 mpam 配套用户态工具 + +### 跨领域和面向外部的流程 + + 由该SIG定义和执行的，且跨领域和面向外部的流程和行动： + + - 非内部流程清单 + - 该SIG拥有的面向整个openEulerSIG的组织指导计划等 diff --git a/sig/sigs.yaml b/sig/sigs.yaml index 9a6e01a..9760ba4 100644 --- a/sig/sigs.yaml +++ b/sig/sigs.yaml @@ -4149,4 +4149,7 @@ sigs: - name: sig-RaspberryPi repositories: - openeuler/raspberrypi - - openeuler/raspberrypi-kernel \ No newline at end of file + - openeuler/raspberrypi-kernel +- name: sig-mpam + repositories: + - openeuler/mpam -- 2.20.1

1 0

[PATCH] apply to add a new mpam sig
by Xie XiuQi 06 Apr '20

06 Apr '20

MPAM is a new feature on Kunpeng platform, which is used to control LLC and memory bandwidth allocation and monitoring. SIG Mission and Scope: - enable mpam feature on Kunpeng Platform - develop supporting tools - assist the application in actual scenarios - improve MPAM according to the requirements of application scenarios - explore new application scenarios for MPAM - through more applications and tests, push the MPAM driver into the kernel upstream Signed-off-by: Xie XiuQi <xiexiuqi(a)huawei.com> --- repository/openeuler.yaml | 5 ++++ sig/sig-mpam/sig-mpam.md | 48 +++++++++++++++++++++++++++++++++++++ sig/sig-mpam/sig-mpam_cn.md | 29 ++++++++++++++++++++++ sig/sigs.yaml | 5 +++- 4 files changed, 86 insertions(+), 1 deletion(-) create mode 100644 sig/sig-mpam/sig-mpam.md create mode 100644 sig/sig-mpam/sig-mpam_cn.md diff --git a/repository/openeuler.yaml b/repository/openeuler.yaml index f91d628..23584c5 100644 --- a/repository/openeuler.yaml +++ b/repository/openeuler.yaml @@ -151,3 +151,8 @@ repositories: protected_branches: - master type: public +- name: mpam + description: "Memory System Resource Partitioning and Monitoring" + protected_branches: + - master + type: public diff --git a/sig/sig-mpam/sig-mpam.md b/sig/sig-mpam/sig-mpam.md new file mode 100644 index 0000000..743486f --- /dev/null +++ b/sig/sig-mpam/sig-mpam.md @@ -0,0 +1,48 @@ +# Application to create mpam SIG +English | [��](./sig-template_cn.md) + +MPAM is a new feature on Kunpeng platform, which is used to control LLC +and memory bandwidth allocation and monitoring. + +## SIG Mission and Scope + +- enable mpam feature on Kunpeng Platform +- develop supporting tools +- assist the application in actual scenarios +- improve MPAM according to the requirements of application scenarios +- explore new application scenarios for MPAM +- through more applications and tests, push the MPAM driver into the kernel upstream + +### Deliverables + +- mpam document: https://gitee.com/openeuler/mpam +- mpam drivers (inlcuded in kernel tree): https://gitee.com/openeuler/kernel +- mpam supporting tools (todo) + +### Repositories and description managed by this SIG + + +### Cross-domain and external-oriented processes + +## Basic Information + +### Project Introduction +��https: /gitee.com/openeuler/community/sig/sig-mpam/ + +``` +### Maintainers +- Xie XiuQi [@xiexiuqi](https://gitee.com/xiexiuqi) +- Wang Shaobo [@jentlestea](https://gitee.com/jentlestea) + +### Committers +- Xie XiuQi [@xiexiuqi](https://gitee.com/xiexiuqi) +- Wang Shaobo [@jentlestea](https://gitee.com/jentlestea) + +### Mailing list +- kernel(a)openeuler.org + +### IRC Channel +NA + +``` + diff --git a/sig/sig-mpam/sig-mpam_cn.md b/sig/sig-mpam/sig-mpam_cn.md new file mode 100644 index 0000000..6ffc41b --- /dev/null +++ b/sig/sig-mpam/sig-mpam_cn.md @@ -0,0 +1,29 @@ +# openEuler MPAM �� +[English](./sig-mpam.md) | �� + +MPAM(Memory Partitioning and Monitoring) ��920�� Cache, +��, +MPAM��LLC�� + +## SIG�� + +- �� MPAM �� +- �� MPAM ��, �� +- �� MPAM �� +- �� MPAM +- �� MPAM �� +- ��MPAM�� + +### ��SIG��repository�� + +- �� + - mpam document��https://gitee.com/openeuler/mpam + - mpam �� kernel ��https://gitee.com/openeuler/kernel + - �� mpam �� + +### �� + + ��SIG�� + + - �� + - ��SIG��openEulerSIG�� diff --git a/sig/sigs.yaml b/sig/sigs.yaml index 9a6e01a..9760ba4 100644 --- a/sig/sigs.yaml +++ b/sig/sigs.yaml @@ -4149,4 +4149,7 @@ sigs: - name: sig-RaspberryPi repositories: - openeuler/raspberrypi - - openeuler/raspberrypi-kernel \ No newline at end of file + - openeuler/raspberrypi-kernel +- name: sig-mpam + repositories: + - openeuler/mpam -- 2.20.1

2 1

回复:Re: 答复: [PATCH] KYLIN: hns3: fix a compilation error
by Zhengyuan Liu 31 Mar '20

31 Mar '20

Glad to. I will resend a V2. ---------- 该邮件从移动设备发送 --------------原始邮件-------------- 发件人："Xie XiuQi "<xiexiuqi(a)huawei.com>gt;; 发送时间：2020年3月31日(星期二) 上午10:57 收件人："huangdaode" <huangdaode(a)huawei.com>gt;;"Guohanjun (Hanjun Guo)" <guohanjun(a)huawei.com>gt;;"Zhengyuan Liu" <liuzhengyuan(a)tj.kylinos.cn>gt;;"kernel(a)openeuler.org" <kernel(a)openeuler.org>gt;;"lipeng (Y)" <lipeng321(a)huawei.com>gt;; 主题：Re: 答复: [PATCH] KYLIN: hns3: fix a compilation error ----------------------------------- Hi Zhengyuan, Would you please resend a patch to remove those ccflags? Thanks! On 2020/3/31 9:34, huangdaode wrote: > Yes, I don't think we need these flags in open kernel tree, it's for product compile. > > -----邮件原件----- > 发件人: Xiexiuqi > 发送时间: 2020年3月27日 17:14 > 收件人: Guohanjun (Hanjun Guo) <guohanjun(a)huawei.com>gt;; Zhengyuan Liu <liuzhengyuan(a)tj.kylinos.cn>gt;; kernel(a)openeuler.org; huangdaode <huangdaode(a)huawei.com>gt;; lipeng (Y) <lipeng321(a)huawei.com> > 主题: Re: [PATCH] KYLIN: hns3: fix a compilation error > > Hi Li Peng & Daode, > > Please help to check this patch about hns3's Makefile. > > On 2020/3/27 11:38, Hanjun Guo via Kernel wrote: >> On 2020/3/25 9:12, Zhengyuan Liu wrote: >>> >>> >>> On 2020/3/24 下午9:22, Hanjun Guo wrote: >>>> Hi Zhengyuan, >>>> >>>> On 2020/3/20 18:55, Zhengyuan Liu via Kernel wrote: >>>>> From: Zhengyuan Liu <liuzhengyuan(a)kylinos.cn> >>>>> >>>>> Make stack-protector-strong building flag depend on >>>>> CONFIG_STACKPROTECTOR_STRONG, otherwise there could be a >>>>> copmilation error: >>>>> >>>>>     MODPOST 1532 modules >>>>>     ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hns3_cae.ko] undefined! >>>>>     ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hns3_cae.ko] undefined! >>>>>     ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hns3.ko] undefined! >>>>>     ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hns3.ko] undefined! >>>>>     ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hclgevf.ko] undefined! >>>>>     ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hclgevf.ko] undefined! >>>>>     ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hclge.ko] undefined! >>>>>     ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hclge.ko] undefined! >>>>>     make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1 >>>>> >>>>> Signed-off-by: Zhengyuan Liu <liuzhengyuan(a)kylinos.cn> >>>>> --- >>>>>   drivers/net/ethernet/hisilicon/hns3/Makefile | 2 ++ >>>>>   1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile >>>>> b/drivers/net/ethernet/hisilicon/hns3/Makefile >>>>> index 6653e81ede9a..f4952f46be7f 100644 >>>>> --- a/drivers/net/ethernet/hisilicon/hns3/Makefile >>>>> +++ b/drivers/net/ethernet/hisilicon/hns3/Makefile >>>>> @@ -4,7 +4,9 @@ >>>>>   # >>>>>     # Add security options >>>>> +ifdef CONFIG_STACKPROTECTOR_STRONG >>>>>   ccflags-y += -fstack-protector-strong >>>> >>>> I'm not sure why we need this compile option, seems we need to >>>> remove all those ccflags-y in this file, I will take a look and get >>>> back to you. >>> >>> Hi Hanjun, thanks for your reply. I'm curious about that ccflags too, the upstream seems to haven't those flags. >> >> I think we need to remove those ccflags, could you please send another >> version of the patch? > > Hi, Hanjun, > I agree with you, we do not need this ccflags in kernel tree. > What do you think, Li Peng & Daode? > > @Li Peng, @Huang Daode. > >> >> Thanks >> Hanjun >> _______________________________________________ >> Kernel mailing list -- kernel(a)openeuler.org To unsubscribe send an >> email to kernel-leave(a)openeuler.org >> >

1 0

Re: [PATCH] KYLIN: hns3: fix a compilation error
by Hanjun Guo 31 Mar '20

31 Mar '20

On 2020/3/25 9:12, Zhengyuan Liu wrote: > > > On 2020/3/24 下午9:22, Hanjun Guo wrote: >> Hi Zhengyuan, >> >> On 2020/3/20 18:55, Zhengyuan Liu via Kernel wrote: >>> From: Zhengyuan Liu <liuzhengyuan(a)kylinos.cn> >>> >>> Make stack-protector-strong building flag depend on >>> CONFIG_STACKPROTECTOR_STRONG, otherwise there could >>> be a copmilation error: >>> >>> MODPOST 1532 modules >>> ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hns3_cae.ko] undefined! >>> ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hns3_cae.ko] undefined! >>> ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hns3.ko] undefined! >>> ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hns3.ko] undefined! >>> ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hclgevf.ko] undefined! >>> ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hclgevf.ko] undefined! >>> ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hclge.ko] undefined! >>> ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hclge.ko] undefined! >>> make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1 >>> >>> Signed-off-by: Zhengyuan Liu <liuzhengyuan(a)kylinos.cn> >>> --- >>> drivers/net/ethernet/hisilicon/hns3/Makefile | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile b/drivers/net/ethernet/hisilicon/hns3/Makefile >>> index 6653e81ede9a..f4952f46be7f 100644 >>> --- a/drivers/net/ethernet/hisilicon/hns3/Makefile >>> +++ b/drivers/net/ethernet/hisilicon/hns3/Makefile >>> @@ -4,7 +4,9 @@ >>> # >>> # Add security options >>> +ifdef CONFIG_STACKPROTECTOR_STRONG >>> ccflags-y += -fstack-protector-strong >> >> I'm not sure why we need this compile option, seems we need to remove >> all those ccflags-y in this file, I will take a look and get back to >> you. > > Hi Hanjun, thanks for your reply. I'm curious about that ccflags too, the upstream seems to haven't those flags. I think we need to remove those ccflags, could you please send another version of the patch? Thanks Hanjun

3 3

Re: [Tc] SIG组工作审视
by Fred Li 27 Mar '20

27 Mar '20

Happy to see technical committee members will mentor us. Many thanks in advance. On Fri, Mar 27, 2020 at 7:54 PM myeuler <myeuler(a)163.com> wrote: > > Hi, All tc members, Please do the SIG work review according to this list: > 1. xinwei hu : Virt, system-tool, storage, sig-kernel, sig-community > 2. hong xie : sig-bounds_checking_function, sig-ai-bigdata, security-committee, Runtime, Programming-language > 3. hanjun guo : Private, Packaging, oVirt, Others, Networking, > 4. xiuqi Xie : Kernel, kae, iSulad, Infrastructure, doc > 5. hailiang Zhang : Desktop, DB, Container, Computing > 6. Xun Wang : Compiler, Base-service, A-Tune, atune > 7 Wei Xiong : dev-util, Application, sig-template, sig-mate-desktop > > 请各位委员按照上述的分组对SIG组进行审视，审视的内容包含： > 1. SIG组是否正常运作。是否有明确的负责人。 > 2. 相关的项目是否已经有输出，相关软件是否已经进入gitee仓。 > 3. 相关SIG的主页面是否有明确的介绍信息和完善的说明。 > > 下次TC meeting我们审视一下这些SIG的运作，一些SIG是否需要保留或者合并请各位委员给出建议和意见。 > > 谢谢。 > > > > > _______________________________________________ > Tc mailing list -- tc(a)openeuler.org > To unsubscribe send an email to tc-leave(a)openeuler.org -- Regards Fred Li (李永乐)

1 0

re: How to get guaranteed TF for openeuler.org ?
by ETTA 27 Mar '20

27 Mar '20

Here is how, Guranteed TF above 20 or 30 http://www.str8-creative.io/product/trust-flow-seo-package/ That equals immediate higher rankings TF report attached Regards ETTA Unsubscribe option is available on the footer of our website

1 0

[PATCH] KYLIN: hns3: fix a compilation error
by Zhengyuan Liu 25 Mar '20

25 Mar '20

From: Zhengyuan Liu <liuzhengyuan(a)kylinos.cn> Make stack-protector-strong building flag depend on CONFIG_STACKPROTECTOR_STRONG, otherwise there could be a copmilation error: MODPOST 1532 modules ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hns3_cae.ko] undefined! ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hns3_cae.ko] undefined! ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hns3.ko] undefined! ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hns3.ko] undefined! ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hclgevf.ko] undefined! ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hclgevf.ko] undefined! ERROR: "__stack_chk_fail" [drivers/net/ethernet/hisilicon/hns3/hclge.ko] undefined! ERROR: "__stack_chk_guard" [drivers/net/ethernet/hisilicon/hns3/hclge.ko] undefined! make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1 Signed-off-by: Zhengyuan Liu <liuzhengyuan(a)kylinos.cn> --- drivers/net/ethernet/hisilicon/hns3/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile b/drivers/net/ethernet/hisilicon/hns3/Makefile index 6653e81ede9a..f4952f46be7f 100644 --- a/drivers/net/ethernet/hisilicon/hns3/Makefile +++ b/drivers/net/ethernet/hisilicon/hns3/Makefile @@ -4,7 +4,9 @@ # # Add security options +ifdef CONFIG_STACKPROTECTOR_STRONG ccflags-y += -fstack-protector-strong +endif ccflags-y += -Wl,-z,relro,-z,now ccflags-y += -Wl,-z,noexecstack ccflags-y += -D_FORTIFY_SOURCE=2 -O2 -- 2.20.1

2 2

[PATCH 0/2] livepatch/core: support jump_label
by Cheng Jian 24 Mar '20

24 Mar '20

livepatch/core: support jump_label Cheng Jian (2): livepatch/core: support jump_label livepatch/core: fix kabi for klp_rel_state include/linux/jump_label.h | 1 + include/linux/module.h | 43 +++++++++++++++++++++++++++++++++++++++++++ kernel/jump_label.c | 16 ++++++++++++++++ kernel/livepatch/core.c | 7 +++++++ kernel/module.c | 5 ++++- 5 files changed, 71 insertions(+), 1 deletion(-) -- 2.7.4

1 2

Re: openEuler-1.0是否完整支持mpam功能
by Xie XiuQi 23 Mar '20

23 Mar '20

On 2020/3/23 9:56, haoxin wrote: > 非常感谢您的回复，谢谢，我还想问下，intel rdt resctrl挂载后下有很多配置文件，例如mon_data下的llc_occupancy、mbm_local_bytes、mbm_total_bytes等，这些是在后续会实现还是不再提供类似文件？ > 近期暂时还没有改动，后续支持鲲鹏930的版本可以考虑。当前如果有场景确实需要，以及有效果的话，也可以考虑提供。 > > > > > > 在 2020-03-23 09:38:58，"Xie XiuQi via Kernel" <kernel(a)openeuler.org> 写道： >> >> >>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. >>> >>> >>> >>> >>> >>_______________________________________________ >>Kernel mailing list -- kernel(a)openeuler.org >>To unsubscribe send an email to kernel-leave(a)openeuler.org > > > > >

1 0

Re: openEuler-1.0是否完整支持mpam功能
by Xie XiuQi 23 Mar '20

23 Mar '20

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. > > > > >

1 0

2024

2023

2022

2021

2020

2019

Kernel