March 2020 - Kernel - mailweb.openeuler.org

[PATCH v2] net: hns3: remove the unnecessary ccflags
by Zhengyuan Liu 28 Apr '20

28 Apr '20

category: other bugzilla: NA CVE: NA ---------------------------------- The ccflags removed in this patch shouldn't be in open kernel tree. Especially for -fstack-protector-strong, there will be a compile error when CONFIG_STACKPROTECTOR_STRONG isn't enabled. Signed-off-by: Zhengyuan Liu <liuzhengyuan(a)tj.kylinos.cn> --- drivers/net/ethernet/hisilicon/hns3/Makefile | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile b/drivers/net/ethernet/hisilicon/hns3/Makefile index 6653e81..0365f1c 100644 --- a/drivers/net/ethernet/hisilicon/hns3/Makefile +++ b/drivers/net/ethernet/hisilicon/hns3/Makefile @@ -3,15 +3,6 @@ # Makefile for the HISILICON network device drivers. # -# Add security options -ccflags-y += -fstack-protector-strong -ccflags-y += -Wl,-z,relro,-z,now -ccflags-y += -Wl,-z,noexecstack -ccflags-y += -D_FORTIFY_SOURCE=2 -O2 -ccflags-y += -fvisibility=hidden -ccflags-y += -Wformat=2 -Wfloat-equal -ccflags-y += -fsigned-char - ccflags-y += -DCONFIG_IT_VALIDATION ccflags-y += -DCONFIG_HNS3_TEST -- 2.7.4

3 2

[PATCH 00/22] Add support for Hygon Dhyana Family 18h processor
by Pu Wen 20 Apr '20

20 Apr '20

As a new x86 CPU Vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co., Ltd., and aims at providing high performance x86 processor for China server market. The first generation Hygon's processor(Dhyana) originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different CPU Vendor ID("HygonGenuine")/PCIE Device Vendor ID (0x1D94)/Family series number (Family 18h). To enable the support of Linux kernel to Hygon's CPU, we added a new vendor type (X86_VENDOR_HYGON, with value of 9) in arch/x86/include/ asm/processor.h, and shared most of kernel support codes with AMD family 17h. As Hygon will negotiate with AMD to make sure that only Hygon will use family 18h, so try to minimize code modification and share most codes with AMD under this consideration. This patch series have been applied and tested successfully on Hygon Dhyana SoC silicon. Also tested on AMD EPYC (Family 17h) processor, it works fine and makes no harm to the existing codes. This patch series are created for the current branch openEuler-1.0-LTS. References: [1] Linux kernel patches for Hygon Dhyana, merged in 4.20: https://git.kernel.org/tip/c9661c1e80b609cd038db7c908e061f0535804ef [2] MSR and CPUID definition: https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0… Pu Wen (22): x86/cpu: Create Hygon Dhyana architecture support file x86/cpu: Get cache info and setup cache cpumap for Hygon Dhyana x86/cpu/mtrr: Support TOP_MEM2 and get MTRR number x86/smpboot: Do not use BSP INIT delay and MWAIT to idle on Dhyana x86/events: Add Hygon Dhyana support to PMU infrastructure x86/alternative: Init ideal_nops for Hygon Dhyana x86/amd_nb: Check vendor in AMD-only functions x86/pci, x86/amd_nb: Add Hygon Dhyana support to PCI and northbridge x86/apic: Add Hygon Dhyana support x86/bugs: Add Hygon Dhyana to the respective mitigation machinery x86/mce: Add Hygon Dhyana support to the MCA infrastructure x86/kvm: Add Hygon Dhyana support to KVM x86/xen: Add Hygon Dhyana support to Xen ACPI: Add Hygon Dhyana support cpufreq: Add Hygon Dhyana support EDAC, amd64: Add Hygon Dhyana support tools/cpupower: Add Hygon Dhyana support hwmon: (k10temp) Add Hygon Dhyana support x86/CPU/hygon: Fix phys_proc_id calculation logic for multi-die processors i2c-piix4: Add Hygon Dhyana SMBus support x86/amd_nb: Make hygon_nb_misc_ids static NTB: Add Hygon Device ID Documentation/i2c/busses/i2c-piix4 | 2 + MAINTAINERS | 6 + arch/x86/Kconfig.cpu | 14 + arch/x86/events/amd/core.c | 4 + arch/x86/events/amd/uncore.c | 20 +- arch/x86/events/core.c | 4 + arch/x86/include/asm/amd_nb.h | 3 + arch/x86/include/asm/cacheinfo.h | 1 + arch/x86/include/asm/kvm_emulate.h | 4 + arch/x86/include/asm/mce.h | 2 + arch/x86/include/asm/processor.h | 3 +- arch/x86/include/asm/virtext.h | 5 +- arch/x86/kernel/alternative.c | 4 + arch/x86/kernel/amd_nb.c | 49 ++- arch/x86/kernel/apic/apic.c | 7 + arch/x86/kernel/apic/probe_32.c | 1 + arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/bugs.c | 4 +- arch/x86/kernel/cpu/cacheinfo.c | 31 +- arch/x86/kernel/cpu/common.c | 4 + arch/x86/kernel/cpu/cpu.h | 1 + arch/x86/kernel/cpu/hygon.c | 413 ++++++++++++++++++ arch/x86/kernel/cpu/mce/core.c | 20 +- arch/x86/kernel/cpu/mce/severity.c | 3 +- arch/x86/kernel/cpu/mtrr/cleanup.c | 3 +- arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- arch/x86/kernel/cpu/perfctr-watchdog.c | 2 + arch/x86/kernel/smpboot.c | 4 +- arch/x86/kvm/emulate.c | 11 +- arch/x86/pci/amd_bus.c | 6 +- arch/x86/xen/pmu.c | 12 +- drivers/acpi/acpi_pad.c | 1 + drivers/acpi/processor_idle.c | 1 + drivers/cpufreq/acpi-cpufreq.c | 5 + drivers/cpufreq/amd_freq_sensitivity.c | 9 +- drivers/edac/amd64_edac.c | 10 +- drivers/edac/mce_amd.c | 4 +- drivers/hwmon/k10temp.c | 3 +- drivers/i2c/busses/Kconfig | 1 + drivers/i2c/busses/i2c-piix4.c | 15 +- drivers/ntb/hw/amd/ntb_hw_amd.c | 1 + include/linux/pci_ids.h | 2 + tools/power/cpupower/utils/cpufreq-info.c | 6 +- tools/power/cpupower/utils/helpers/amd.c | 4 +- tools/power/cpupower/utils/helpers/cpuid.c | 8 +- tools/power/cpupower/utils/helpers/helpers.h | 2 +- tools/power/cpupower/utils/helpers/misc.c | 2 +- .../utils/idle_monitor/mperf_monitor.c | 3 +- 48 files changed, 668 insertions(+), 55 deletions(-) create mode 100644 arch/x86/kernel/cpu/hygon.c -- 2.23.0

5 28

回复: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 March 2020