约束限制

本章节介绍该特性的通用约束,每个子特性会有具体的约束,在对应的小节中详细说明。

兼容性限制

  1. 本特性目前仅适用于ARM64。
  2. 硬件需支持部分MR内存(address range mirror),即通过UEFI标准接口上报属性为EFI_MEMORY_MORE_RELIABLE的内存,普通内存无需额外置位。镜像内存(MR)对应为高可靠内存,普通内存对应为低可靠内存。
  3. 高低可靠内存分级借助内核的内存管理区(zone)来实现,两者无法进行动态流动(即页面不能在不同zone之间移动)。
  4. 不同可靠性的连续物理内存会被分隔到不同的memblock,可能会导致原本可以申请大块连续物理内存的场景在使能内存分级后受到限制。
  5. 本特性使能需要依赖启动参数kernelcore的取值为“kernelcore=reliable”,与该参数其他取值均不兼容。

设计规格限制

  1. 内核态开发时,内存申请操作需要注意:

    • 若内存申请接口支持指定gfp_flag,只有gfp_flag包含__GFP_HIGHMEM且__GFP_MOVABLE的内存申请会强制普通内存区域分配或者将这次内存分配重定向可靠内存区域,其他gfp_flag都不会进行干预。

    • 从slab/slub/slob申请获取的都是高可靠内存(一次性申请内存大于KMALLOC_MAX_CACHE_SIZE时且gfp_flag指定为普通内存区域时可能申请到低可靠内存)。

  2. 用户态开发时,内存申请操作需要注意:

    • 更改普通进程属性为关键进程后,实际物理内存分配阶段(page fault)才会使用高可靠内存,此前已分配的内存属性不会改变,反之亦然。因此普通进程被拉起到更改关键进程属性期间申请的内存可能不是高可靠内存。是否生效可以通过查询虚拟地址对应的物理地址是否属于高可靠内存段来验证。
    • Libc库如glibc中chunk等类似机制(ptmalloc、tcmalloc、dpdk)为了提高性能存在使用cache的逻辑,而内存cache会导致用户申请内存与内核内存申请逻辑不能完全对应,普通进程变成关键进程时并不能真正使能(该标记仅仅在内核实际发生内存申请时使能)。
  3. 当上层业务申请内存的时发现高可靠内存不足(触发zone原生min水线)或者触发对应limit限制,会优先释放pagecache以尝试回收高可靠内存。如果仍然申请不到,内核会根据fallback的开关选择oom或fallback到低可靠内存区域完成内存申请。(fallback指某个内存管理区/节点内存不足时,到其他内存管理区/节点申请内存的情况。)

  4. 类似于NUMA_BALANCING的内存动态迁移机制,可能导致已经分配的高/低可靠内存被迁移到别的节点,由于该迁移操作丢失内存申请的上下文,且目标node可能没有对应可靠性的内存,因此可能导致迁移后的内存可靠性与预期不符。

  5. 按照用户态高可靠内存用途引入如下三个配置文件:

    • /proc/sys/vm/task_reliable_limit: 关键进程(包含systemd)使用的高可靠内存上限。包含匿名页和文件页。进程使用的shmem也会被统计到其中(包含在匿名页中)。

    • /proc/sys/vm/reliable_pagecache_max_bytes:全局pagecache使用的高可靠内存软上限。约束普通进程使用的高可靠pagecache的数量,系统默认不限制pagecache使用的高可靠内存的量。高可靠进程和文件系统元数据等场景不受此约束。无论fallback开关是否开启,普通进程触发该上限时,会默认申请低可靠内存,若低可靠内存申请不到,则遵循原生流程处理。

    • /proc/sys/vm/shmem_reliable_bytes_limit:全局shmem使用的高可靠内存软上限。约束普通进程shmem使用高可靠内存的数量,系统默认不限制shmem使用的高可靠内存的量。高可靠进程不受此约束。关闭fallback时,普通进程触发该上限会导致内存申请失败,但不会OOM(与原生流程一致)。

    触及这些值可能会导致内存申请fallback或者OOM。

    关键进程在tmpfs或pagecache流程产生缺页引发的内存申请,有可能触发多个limit,多个limit之间交互关系情况详见表格。

    是否触及task_reliable_limit是否触及reliable_pagecache_max_bytes或者shmem_reliable_bytes_limit内存申请处理策略
    优先回收pagecache以满足申请,否则Fallback或者OOM
    优先回收pagecache以满足申请,否则Fallback或者OOM
    先高可靠内存,失败Fallback或者OOM
    先高可靠内存,失败Fallback或者OOM

    关键进程会遵循task_reliable_limit的限制,如果task_reliable_limit高于tmpfs或pagecachelimit时,由关键进程产生的pagecache、tmpfs依旧会使用高可靠内存,由此会产生pagecache、tmpfs使用高可靠内存数量高于对应Limit的情况。

    当触发task_reliable_limit,如果高可靠filecache低于4M,不会进行同步回收。如果pagecache产生时,高可靠filecache低于4M,那么会fallback到低可靠内存完成申请,如果达到或高于4M那么会优先回收pagecache满足此次申请。但接近4M时,会触发更频繁的cache直接回收,由于cache直接回收锁开销大,会导致高cpu占用率,此时文件读写性能接近裸盘性能。

  6. 即使系统存在足够申请的高可靠内存,在如下场景下也存在fallback到低可靠内存区域内存申请的场景。

    • 如果进行无法迁移到其他节点进行内存申请,那么会fallback当前节点的低可靠内存,常用场景举例如下:
    • 如果内存申请带上了__GFP_THISNODE(如透明大页申请),代表只能从当前节点申请内存,如果此节点高可靠内存不满足申请情况,那么会尝试从本内存节点的低可靠内存区域进行内存申请。
    • 进程通过taskset、numactl等命令运行在某个包含普通内存节点。
    • 进程在系统内存原生的调度机制下调度到了某个包含普通内存节点。
    • 高可靠内存申请触发高可靠内存使用水线也会导致fallback到低可靠。
  7. 内存分级fallback关闭时,高可靠内存将不能向低可靠内存扩展,有可能导致用户态应用对内存用量的判断与本特性不兼容,比如通过MemFree判断可用内存量。

  8. 内存分级fallback开启时,对原生fallback有影响,主要区别在于内存管理区zone与NUMA节点的选择上,列举如下:

  • 普通用户进程fallback流程将会是: 本节点低可靠内存->远端节点低可靠内存。
  • 关键用户进程fallback流程将会是:本节点高可靠内存-> 远端节点高可靠内存。如果还未申请到内存且开启了memory reliable的fallback功能,将会额外重试: 本节点低可靠内存-> 远端节点低可靠内存。

场景限制

  1. 默认页面大小(PAGE_SIZE)只支持4K页面大小。
  2. Numa Node0上低4G内存必须要为高可靠且高可靠内存大小与低可靠内存大小满足内核使用,否则可能导致系统无法启动。其他node的高可靠内存空间大小无要求,但需注意: 某个node上没有高可靠内存或者高可靠内存不足,可能导致per-node管理结构位于其他node的高可靠内存上(因为其为内核数据结构需要在高可靠区域),由此会产生内核warning,如vmemmap会产生vmemmap_verify相关告警且存在性能影响。
  3. 本特性部分统计值(比如tmpfs高可靠总量)使用percpu技术进行统计,会有额外开销,计算总和时考虑到减少性能影响。因此存在一定的误差,误差10%内属于正常。
  4. 大页限制:
    • 启动阶段静态大页为低可靠内存,运行时申请的静态大页默认为低可靠内存,如果内存申请发生在关键进程上下文,那么申请到的大页为高可靠内存。
    • 透明大页THP场景下,通过扫描进行合并大页(2M页为例)时如果待合并的512个4k页面中某一个为高可靠页面,那么新申请的2M大页会使用高可靠内存,透明大页会导致使用更多高可靠内存。
    • 2M大页预留申请遵循原生的fallback流程,如果当前node缺少低可靠内存,那么会fallback高可靠区间申请高可靠完成内存申请。
    • 启动阶段进行2M大页预留,如果没有指定内存节点,那么会负载均衡到每个内存节点进行大页的预留。如果某个内存节点缺少低可靠内存,那么会遵循原生流程使用高可靠。
  5. 当前仅仅支持正常系统启动场景。部分异常场景内核启动可能与内存分级功能不兼容,如kdump启动阶段(当前kdump已支持自动关闭,其他场景需要上层业务关闭。)
  6. SWAP换入换出、内存offline、KSM、cma、giganic page流程下新申请的页面类型没有基于分级内存进行考量,可能出现未定义情况(未定义情况包括高可靠用量统计不准、申请到的内存可靠性等级与预期不符等)。

性能影响

  • 物理页申请因分级管理的引入而增加了判断逻辑,会有一些性能影响,具体影响程度与系统状况、申请内存类型、各节点高低可靠内存余量有关。
  • 本特性引入高可靠内存相关用量统计值,会对系统性能产生影响。
  • 触发task_reliable_limit时,会对位于高可靠区域的cache同步回收,会增加CPU占用率。pagecache申请(文件读写操作,比如dd)触发task_reliable_limit的场景下,如果当前高可靠内存可用量(ReliableFileCache视为可用内存)接近4M时,会触发更频繁的cache直接回收,由于cache直接回收锁开销大,会导致高cpu占用率。此时文件读写性能接近裸盘性能。

文档捉虫

“有虫”文档片段

问题描述

提交类型 issue
有点复杂...
找人问问吧。
PR
小问题,全程线上修改...
一键搞定!
问题类型
规范和低错类

● 错别字或拼写错误;标点符号使用错误;

● 链接错误、空单元格、格式错误;

● 英文中包含中文字符;

● 界面和描述不一致,但不影响操作;

● 表述不通顺,但不影响理解;

● 版本号不匹配:如软件包名称、界面版本号;

易用性

● 关键步骤错误或缺失,无法指导用户完成任务;

● 缺少必要的前提条件、注意事项等;

● 图形、表格、文字等晦涩难懂;

● 逻辑不清晰,该分类、分项、分步骤的没有给出;

正确性

● 技术原理、功能、规格等描述和软件不一致,存在错误;

● 原理图、架构图等存在错误;

● 命令、命令参数等错误;

● 代码片段错误;

● 命令无法完成对应功能;

● 界面错误,无法指导操作;

风险提示

● 对重要数据或系统存在风险的操作,缺少安全提示;

内容合规

● 违反法律法规,涉及政治、领土主权等敏感词;

● 内容侵权;

您对文档的总体满意度

非常不满意
非常满意
提交
根据您的反馈,会自动生成issue模板。您只需点击按钮,创建issue即可。