[PATCH 00/12] docs/zh_CN: add a little vm translation

linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* [PATCH 00/12] docs/zh_CN: add a little vm translation
@ 2022-03-05 16:26 Yanteng Si
  2022-03-05 16:26 ` [PATCH 01/12] docs/zh_CN: add vm frontswap translation Yanteng Si
                   ` (11 more replies)
  0 siblings, 12 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

v1:
* Translate a little .../vm/*.rst into Chinese.

* It is expected that all vm documentation will be
 translated in a short time, sorry for the huge review
 pressure on maintainer. I look like a troublemaker. >_<

Yanteng Si (12):
  docs/zh_CN: add vm frontswap translation
  docs/zh_CN: add vm hwpoison translation
  docs/zh_CN: add vm memory-model translation
  docs/zh_CN: add vm mmu_notifier translation
  docs/zh_CN: add vm overcommit-accounting translation
  docs/zh_CN: add vm page_frags translation
  docs/zh_CN: add vm page_owner translation
  docs/zh_CN: add vm page_table_check translation
  docs/zh_CN: add vm remap_file_pages translation
  docs/zh_CN: add vm split_page_table_lock translation
  docs/zh_CN: add vm z3fold translation
  docs/zh_CN: add vm zsmalloc translation

 .../translations/zh_CN/vm/frontswap.rst       | 196 ++++++++++++++++++
 .../translations/zh_CN/vm/hwpoison.rst        | 166 +++++++++++++++
 Documentation/translations/zh_CN/vm/index.rst |  24 +--
 .../translations/zh_CN/vm/memory-model.rst    | 135 ++++++++++++
 .../translations/zh_CN/vm/mmu_notifier.rst    |  97 +++++++++
 .../zh_CN/vm/overcommit-accounting.rst        |  86 ++++++++
 .../translations/zh_CN/vm/page_frags.rst      |  38 ++++
 .../translations/zh_CN/vm/page_owner.rst      | 116 +++++++++++
 .../zh_CN/vm/page_table_check.rst             |  56 +++++
 .../zh_CN/vm/remap_file_pages.rst             |  32 +++
 .../zh_CN/vm/split_page_table_lock.rst        |  96 +++++++++
 .../translations/zh_CN/vm/z3fold.rst          |  31 +++
 .../translations/zh_CN/vm/zsmalloc.rst        |  78 +++++++
 13 files changed, 1139 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/translations/zh_CN/vm/frontswap.rst
 create mode 100644 Documentation/translations/zh_CN/vm/hwpoison.rst
 create mode 100644 Documentation/translations/zh_CN/vm/memory-model.rst
 create mode 100644 Documentation/translations/zh_CN/vm/mmu_notifier.rst
 create mode 100644 Documentation/translations/zh_CN/vm/overcommit-accounting.rst
 create mode 100644 Documentation/translations/zh_CN/vm/page_frags.rst
 create mode 100644 Documentation/translations/zh_CN/vm/page_owner.rst
 create mode 100644 Documentation/translations/zh_CN/vm/page_table_check.rst
 create mode 100644 Documentation/translations/zh_CN/vm/remap_file_pages.rst
 create mode 100644 Documentation/translations/zh_CN/vm/split_page_table_lock.rst
 create mode 100644 Documentation/translations/zh_CN/vm/z3fold.rst
 create mode 100644 Documentation/translations/zh_CN/vm/zsmalloc.rst

-- 
2.27.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH 01/12] docs/zh_CN: add vm frontswap translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-08 11:49   ` Alex Shi
  2022-03-05 16:26 ` [PATCH 02/12] docs/zh_CN: add vm hwpoison translation Yanteng Si
                   ` (10 subsequent siblings)
  11 siblings, 1 reply; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/_free_page_reporting.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/vm/frontswap.rst       | 196 ++++++++++++++++++
 Documentation/translations/zh_CN/vm/index.rst |   2 +-
 2 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/frontswap.rst

diff --git a/Documentation/translations/zh_CN/vm/frontswap.rst b/Documentation/translations/zh_CN/vm/frontswap.rst
new file mode 100644
index 000000000000..3eb07870e2ef
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/frontswap.rst
@@ -0,0 +1,196 @@
+:Original: Documentation/vm/_free_page_reporting.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+=========
+Frontswap
+=========
+
+Frontswap为交换页提供了一个 “transcendent memory” 的接口。在一些环境中，由
+于交换页被保存在RAM（或类似RAM的设备）中，而不是交换磁盘，因此可以获得巨大的性能
+节省（提高）。
+
+.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
+
+Frontswap之所以这么命名，是因为它可以被认为是与swap设备的“back”存储相反。存
+储器被认为是一个同步并发安全的面向页面的“伪RAM设备”，符合transcendent memory
+（如Xen的“tmem”，或内核内压缩内存，又称“zcache”，或未来的类似RAM的设备）的要
+求；这个伪RAM设备不能被内核直接访问或寻址，其大小未知且可能随时间变化。驱动程序通过
+调用frontswap_register_ops将自己与frontswap链接起来，以适当地设置frontswap_ops
+的功能，它提供的功能必须符合某些策略，如下所示:
+
+一个 “init” 将设备准备好接收与指定的交换设备编号（又称“类型”）相关的frontswap
+交换页。一个 “store” 将把该页复制到transcendent memory，并与该页的类型和偏移
+量相关联。一个 “load” 将把该页，如果找到的话，从transcendent memory复制到内核
+内存，但不会从transcendent memory中删除该页。一个 “invalidate_page” 将从
+transcendent memory中删除该页，一个 “invalidate_area” 将删除所有与交换类型
+相关的页（例如，像swapoff）并通知 “device” 拒绝进一步存储该交换类型。
+
+一旦一个页面被成功存储，在该页面上的匹配加载通常会成功。因此，当内核发现自己处于需
+要交换页面的情况时，它首先尝试使用frontswap。如果存储的结果是成功的，那么数据就已
+经成功的保存到了transcendent memory中，并且避免了磁盘写入，如果后来再读回数据，
+也避免了磁盘读取。如果存储返回失败，transcendent memory已经拒绝了该数据，且该页
+可以像往常一样被写入交换空间。
+
+请注意，如果一个页面被存储，而该页面已经存在于transcendent memory中（一个 “重复”
+的存储），要么存储成功，数据被覆盖，要么存储失败，该页面被废止。这确保了旧的数据永远
+不会从frontswap中获得。
+
+如果配置正确，对frontswap的监控是通过 `/sys/kernel/debug/frontswap` 目录下的
+debugfs完成的。frontswap的有效性可以通过以下方式测量（在所有交换设备中）:
+
+``failed_stores``
+	有多少次存储的尝试是失败的
+
+``loads``
+	尝试了多少次加载（应该全部成功）
+
+``succ_stores``
+	有多少次存储的尝试是成功的
+
+``invalidates``
+	尝试了多少次作废
+
+后台实现可以提供额外的指标。
+
+经常问到的问题
+==============
+
+* 价值在哪里?
+
+当一个工作负载开始交换时，性能就会下降。Frontswap通过提供一个干净的、动态的接口来
+读取和写入交换页到 “transcendent memory”，从而大大增加了许多这样的工作负载的性
+能，否则内核是无法直接寻址的。当数据被转换为不同的形式和大小（比如压缩）或者被秘密
+移动（对于一些类似RAM的设备来说，这可能对写平衡很有用）时，这个接口是理想的。交换
+页（和被驱逐的页面缓存页）是这种比RAM慢但比磁盘快得多的“伪RAM设备”的一大用途。
+
+Frontswap对内核的影响相当小，为各种系统配置中更动态、更灵活的RAM利用提供了巨大的
+灵活性：
+
+在单一内核的情况下，又称“zcache”，页面被压缩并存储在本地内存中，从而增加了可以安
+全保存在RAM中的匿名页面总数。Zcache本质上是用压缩/解压缩的CPU周期换取更好的内存利
+用率。Benchmarks测试显示，当内存压力较低时，几乎没有影响，而在高内存压力下的一些
+工作负载上，则有明显的性能改善（25%以上）。
+
+“RAMster” 在zcache的基础上增加了对集群系统的 “peer-to-peer” transcendent memory
+的支持。Frontswap页面像zcache一样被本地压缩，但随后被“remotified” 到另一个系
+统的RAM。这使得RAM可以根据需要动态地来回负载平衡，也就是说，当系统A超载时，它可以
+交换到系统B，反之亦然。RAMster也可以被配置成一个内存服务器，因此集群中的许多服务器
+可以根据需要动态地交换到配置有大量内存的单一服务器上......而不需要预先配置每个客户
+有多少内存可用
+
+在虚拟情况下，虚拟化的全部意义在于统计地将物理资源在多个虚拟机的不同需求之间进行复
+用。对于RAM来说，这真的很难做到，而且在不改变内核的情况下，要做好这一点的努力基本上
+是失败的（除了一些广为人知的特殊情况下的工作负载）。具体来说，Xen Transcendent Memory
+后端允许管理器拥有的RAM “fallow”，不仅可以在多个虚拟机之间进行“time-shared”，
+而且页面可以被压缩和重复利用，以优化RAM的利用率。当客户操作系统被诱导交出未充分利用
+的RAM时（如 “selfballooning”），突然出现的意外内存压力可能会导致交换；frontswap
+允许这些页面被交换到管理器RAM中或从管理器RAM中交换（如果整体主机系统内存条件允许），
+从而减轻计划外交换可能带来的可怕的性能影响。
+
+一个KVM的实现正在进行中，并且已经被RFC'ed到lkml。而且，利用frontswap，对NVM作为
+内存扩展技术的调查也在进行中。
+
+* 当然，在某些情况下可能有性能上的优势，但frontswap的空间/时间开销是多少？
+
+如果 CONFIG_FRONTSWAP 被禁用，每个 frontswap 钩子都会编译成空，唯一的开销是每
+个 swapon'ed swap 设备的几个额外字节。如果 CONFIG_FRONTSWAP 被启用，但没有
+frontswap的 “backend” 寄存器，每读或写一个交换页就会有一个额外的全局变量，而不
+是零。如果 CONFIG_FRONTSWAP 被启用，并且有一个frontswap的backend寄存器，并且
+后端每次 “store” 请求都失败（即尽管声称可能，但没有提供内存），CPU 的开销仍然可以
+忽略不计 - 因为每次frontswap失败都是在交换页写到磁盘之前，系统很可能是 I/O 绑定
+的，无论如何使用一小部分的 CPU 都是不相关的。
+
+至于空间，如果CONFIG_FRONTSWAP被启用，并且有一个frontswap的backend注册，那么
+每个交换设备的每个交换页都会被分配一个比特。这是在内核已经为每个交换设备的每个交换
+页分配的8位（在2.6.34之前是16位）上增加的。(Hugh Dickins观察到，frontswap可能
+会偷取现有的8个比特，但是我们以后再来担心这个小的优化问题)。对于标准的4K页面大小的
+非常大的交换盘（这很罕见），这是每32GB交换盘1MB开销。
+
+当交换页存储在transcendent memory中而不是写到磁盘上时，有一个副作用，即这可能会
+产生更多的内存压力，有可能超过其他的优点。一个backend，比如zcache，必须实现策略
+来仔细（但动态地）管理内存限制，以确保这种情况不会发生。
+
+* 好吧，那就用内核骇客能理解的术语来快速概述一下这个frontswap补丁的作用如何？
+
+我们假设在内核初始化过程中，一个frontswap 的 “backend” 已经注册了；这个注册表
+明这个frontswap 的 “backend” 可以访问一些不被内核直接访问的“内存”。它到底提
+供了多少内存是完全动态和随机的。
+
+每当一个交换设备被交换时，就会调用frontswap_init()，把交换设备的编号（又称“类
+型”）作为一个参数传给它。这就通知了frontswap，以期待 “store” 与该号码相关的交
+换页的尝试。
+
+每当交换子系统准备将一个页面写入交换设备时（参见swap_writepage()），就会调用
+frontswap_store。Frontswap与frontswap backend协商，如果backend说它没有空
+间，frontswap_store返回-1，内核就会照常把页换到交换设备上。注意，来自frontswap
+backend的响应对内核来说是不可预测的；它可能选择从不接受一个页面，可能接受每九个
+页面，也可能接受每一个页面。但是如果backend确实接受了一个页面，那么这个页面的数
+据已经被复制并与类型和偏移量相关联了，而且backend保证了数据的持久性。在这种情况
+下，frontswap在交换设备的“frontswap_map” 中设置了一个位，对应于交换设备上的
+页面偏移量，否则它就会将数据写入该设备。
+
+当交换子系统需要交换一个页面时（swap_readpage()），它首先调用frontswap_load()，
+检查frontswap_map，看这个页面是否早先被frontswap backend接受。如果是，该页
+的数据就会从frontswap后端填充，换入就完成了。如果不是，正常的交换代码将被执行，
+以便从真正的交换设备上获得这一页的数据。
+
+所以每次frontswap backend接受一个页面时，交换设备的读取和（可能）交换设备的写
+入都被 “frontswap backend store” 和（可能）“frontswap backend loads”
+所取代，这可能会快得多。
+
+* frontswap不能被配置为一个 “特殊的” 交换设备，它的优先级要高于任何真正的交换
+  设备（例如像zswap，或者可能是swap-over-nbd/NFS）？
+
+首先，现有的交换子系统不允许有任何种类的交换层次结构。也许它可以被重写以适应层次
+结构，但这将需要相当大的改变。即使它被重写，现有的交换子系统也使用了块I/O层，它
+假定交换设备是固定大小的，其中的任何页面都是可线性寻址的。Frontswap几乎没有触
+及现有的交换子系统，而是围绕着块I/O子系统的限制，提供了大量的灵活性和动态性。
+
+例如，frontswap backend对任何交换页的接受是完全不可预测的。这对frontswap backend
+的定义至关重要，因为它赋予了backend完全动态的决定权。在zcache中，人们无法预
+先知道一个页面的可压缩性如何。可压缩性 “差” 的页面会被拒绝，而 “差” 本身也可
+以根据当前的内存限制动态地定义。
+
+此外，frontswap是完全同步的，而真正的交换设备，根据定义，是异步的，并且使用
+块I/O。块I/O层不仅是不必要的，而且可能进行 “优化”，这对面向RAM的设备来说是
+不合适的，包括将一些页面的写入延迟相当长的时间。同步是必须的，以确保后端的动
+态性，并避免棘手的竞争条件，这将不必要地大大增加frontswap和/或块I/O子系统的
+复杂性。也就是说，只有最初的 “store” 和 “load” 操作是需要同步的。一个独立
+的异步线程可以自由地操作由frontswap存储的页面。例如，RAMster中的 “remotification”
+线程使用标准的异步内核套接字，将压缩的frontswap页面移动到远程机器。同样，
+KVM的客户方实现可以进行客户内压缩，并使用 “batched” hypercalls。
+
+在虚拟化环境中，动态性允许管理程序（或主机操作系统）做“intelligent overcommit”。
+例如，它可以选择只接受页面，直到主机交换可能即将发生，然后强迫客户机做他们
+自己的交换。
+
+transcendent memory规格的frontswap有一个坏处。因为任何 “store” 都可
+能失败，所以必须在一个真正的交换设备上有一个真正的插槽来交换页面。因此，
+frontswap必须作为每个交换设备的 “影子” 来实现，它有可能容纳交换设备可能
+容纳的每一个页面，也有可能根本不容纳任何页面。这意味着frontswap不能包含比
+swap设备总数更多的页面。例如，如果在某些安装上没有配置交换设备，frontswap
+就没有用。无交换设备的便携式设备仍然可以使用frontswap，但是这种设备的
+backend必须配置某种 “ghost” 交换设备，并确保它永远不会被使用。
+
+
+* 为什么会有这种关于 “重复存储” 的奇怪定义？如果一个页面以前被成功地存储过，
+  难道它不能总是被成功地覆盖吗？
+
+几乎总是可以的，不，有时不能。考虑一个例子，数据被压缩了，原来的4K页面被压
+缩到了1K。现在，有人试图用不可压缩的数据覆盖该页，因此会占用整个4K。但是
+backend没有更多的空间了。在这种情况下，这个存储必须被拒绝。每当frontswap
+拒绝一个会覆盖的存储时，它也必须使旧的数据作废，并确保它不再被访问。因为交
+换子系统会把新的数据写到读交换设备上，这是确保一致性的正确做法。
+
+* 为什么frontswap补丁会创建新的头文件swapfile.h？
+
+frontswap代码依赖于一些swap子系统内部的数据结构，这些数据结构多年来一直
+在静态和全局之间来回移动。这似乎是一个合理的妥协：将它们定义为全局，但在一
+个新的包含文件中声明它们，该文件不被包含swap.h的大量源文件所包含。
+
+Dan Magenheimer，最后更新于2012年4月9日
diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 2f9834eb9475..cc8d68b0cbb5 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -26,11 +26,11 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    damon/index
    free_page_reporting
    highmem
+   frontswap
 
 TODOLIST:
 * arch_pgtable_helpers
 * free_page_reporting
-* frontswap
 * hmm
 * hwpoison
 * hugetlbfs_reserv
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 02/12] docs/zh_CN: add vm hwpoison translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
  2022-03-05 16:26 ` [PATCH 01/12] docs/zh_CN: add vm frontswap translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-08 13:04   ` Alex Shi
  2022-03-05 16:26 ` [PATCH 03/12] docs/zh_CN: add vm memory-model translation Yanteng Si
                   ` (9 subsequent siblings)
  11 siblings, 1 reply; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/hwpoison.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 .../translations/zh_CN/vm/hwpoison.rst        | 166 ++++++++++++++++++
 Documentation/translations/zh_CN/vm/index.rst |   2 +-
 2 files changed, 167 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/hwpoison.rst

diff --git a/Documentation/translations/zh_CN/vm/hwpoison.rst b/Documentation/translations/zh_CN/vm/hwpoison.rst
new file mode 100644
index 000000000000..7c4477c33e56
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/hwpoison.rst
@@ -0,0 +1,166 @@
+
+:Original: Documentation/vm/hwpoison.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+========
+hwpoison
+========
+
+什么是hwpoison?
+===============
+
+
+即将推出的英特尔CPU支持从一些内存错误中恢复（ ``MCA恢复`` ）。这需要操作系统宣布
+一个页面"poisoned"，杀死与之相关的进程，并避免在未来使用它。
+
+这个补丁包在虚拟机中实现了必要的基础设施。
+
+引用概述中的评论::
+
+	高水平的机器检查处理程序。处理被硬件报告为损坏的页面，通常是由于2位ECC内存或
+	高速缓存故障。
+
+	这主要是针对在后台检测到的损坏的页面。当当前的CPU试图访问它时，当前运行的进程
+	可以直接被杀死。这意味着，如果错误由于某种原因不能被处理，就可以安全地忽略它，
+	因为还没有访问损坏的页面。相反，当这种情况发生时，另一个机器检查将出现。
+
+	处理不同状态的页面缓存页。这里棘手的部分是，我们可以异步访问任何页面给其他虚拟
+	机用户，因为内存故障可能随时随地发生，可能违反了他们的一些假设。这就是为什么这
+	段代码必须非常小心。一般来说，它试图使用正常的锁定规则，如获得标准锁，即使这意
+	味着错误处理可能需要很长的时间。
+
+	这里的一些操作有点低效，并且具有非线性的算法复杂性，因为数据结构没有针对这种情
+	况进行优化。特别是从vma到进程的映射就是这种情况。由于这种情况预计是罕见的，我
+	们希望我们可以摆脱这种情况。
+
+该代码由mm/memory-failure.c中的高级处理程序、一个新的页面poison 位和虚拟机中的
+各种检查组成，用来处理poison 的页面。
+
+现在的主要针对的是KVM客户机，但它适用于所有类型的应用程序。支持KVM需要最近的qemu-kvm
+版本。
+
+对于KVM的使用，需要一个新的信号类型，这样KVM就可以用适当的地址将机器检查注入到客户
+机中。这在理论上也允许其他应用程序处理内存故障。我们的期望是，几乎所有的应用程序都不
+会这样做，但一些非常专业的应用程序可能会这样做。
+
+故障恢复模式
+============
+
+有两种（实际上是三种）模式的内存故障恢复可以在。
+
+vm.memory_failure_recovery sysctl 置零:
+	所有的内存故障都会导致panic。请不要尝试恢复。
+
+early kill
+	(可以在全局和每个进程中控制) 一旦检测到错误，立即向应用程序发送SIGBUS 这允许
+	应用程序以温和的方式处理内存错误（例如，放弃受影响的对象） 这是KVM qemu使用的
+	模式。
+
+late kill
+	当应用程序运行到损坏的页面时，发送SIGBUS。这对不知道内存错误的应用程序来说是
+	最好的，默认情况下注意一些页面总是被当作 late kill处理。
+
+用户控制
+========
+
+vm.memory_failure_recovery
+	参阅 sysctl.txt
+
+vm.memory_failure_early_kill
+	全局启用early kill
+
+PR_MCE_KILL
+	设置early/late kill mode/revert 到系统默认值。
+
+	arg1: PR_MCE_KILL_CLEAR:
+		恢复到系统默认值
+	arg1: PR_MCE_KILL_SET:
+		arg2定义了线程特定模式
+
+		PR_MCE_KILL_EARLY:
+			Early kill
+		PR_MCE_KILL_LATE:
+			Late kill
+		PR_MCE_KILL_DEFAULT
+			使用系统全局默认值
+
+	注意，如果你想有一个专门的线程代表进程处理SIGBUS(BUS_MCEERR_AO)，你应该在
+	指定线程上调用prctl(PR_MCE_KILL_EARLY)。否则，SIGBUS将被发送到主线程。
+
+PR_MCE_KILL_GET
+	返回当前模式
+
+测试
+====
+
+* madvise(MADV_HWPOISON, ....) (as root) - 在测试过程中Poison一个页面
+
+* 通过debugfs ``/sys/kernel/debug/hwpoison/`` hwpoison-inject模块
+
+  corrupt-pfn
+	在PFN处注入hwpoison故障，并echoed到这个文件。这做了一些早期过滤，以避
+	免在测试套件中损坏的非预期页面。
+  unpoison-pfn
+	在PFN的Software-unpoison 页面呼应到这个文件。这样，一个页面可以再次被
+	复用。这只对Linux注入的故障起作用，对真正的内存故障不起作用。
+
+  注意这些注入接口并不稳定，可能会在不同的内核版本中发生变化
+
+  corrupt-filter-dev-major, corrupt-filter-dev-minor
+	只处理与块设备major/minor定义的文件系统相关的页面的内存故障。-1U是通
+	配符值。这应该只用于人工注入的测试。
+
+  corrupt-filter-memcg
+	限制注入到memgroup拥有的页面。由memcg的inode号指定。
+
+	Example::
+
+		mkdir /sys/fs/cgroup/mem/hwpoison
+
+	        usemem -m 100 -s 1000 &
+		echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks
+
+		memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ')
+		echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg
+
+		page-types -p `pidof init`   --hwpoison  # shall do nothing
+		page-types -p `pidof usemem` --hwpoison  # poison its pages
+
+  corrupt-filter-flags-mask, corrupt-filter-flags-value
+	当指定时，只有在((page_flags & mask) == value)的情况下才会poison页面。
+	这允许对许多种类的页面进行压力测试。page_flags与/proc/kpageflags中的相
+	同。这些标志位在include/linux/kernel-page-flags.h中定义，并在
+	Documentation/admin-guide/mm/pagemap.rst中记录。
+
+* 架构特定的MCE注入器
+
+  x86 有 mce-inject, mce-test
+
+  在mce-test中的一些便携式hwpoison测试程序，见下文。
+
+引用
+====
+
+http://halobates.de/mce-lc09-2.pdf
+	09年LinuxCon的概述演讲
+
+git://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git
+	测试套件（在tsrc中的hwpoison特定可移植测试）。
+
+git://git.kernel.org/pub/scm/utils/cpu/mce/mce-inject.git
+	x86特定的注入器
+
+
+限制
+====
+- 不是所有的页面类型都被支持，而且永远不会。大多数内核内部对象不能被恢
+  复，目前只有LRU页。
+
+---
+Andi Kleen, 2009年10月
diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index cc8d68b0cbb5..dd0b3d4c0ab8 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -27,12 +27,12 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    free_page_reporting
    highmem
    frontswap
+   hwpoison
 
 TODOLIST:
 * arch_pgtable_helpers
 * free_page_reporting
 * hmm
-* hwpoison
 * hugetlbfs_reserv
 * memory-model
 * mmu_notifier
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 03/12] docs/zh_CN: add vm memory-model translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
  2022-03-05 16:26 ` [PATCH 01/12] docs/zh_CN: add vm frontswap translation Yanteng Si
  2022-03-05 16:26 ` [PATCH 02/12] docs/zh_CN: add vm hwpoison translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-08 12:37   ` Alex Shi
  2022-03-05 16:26 ` [PATCH 04/12] docs/zh_CN: add vm mmu_notifier translation Yanteng Si
                   ` (8 subsequent siblings)
  11 siblings, 1 reply; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/memory-model.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |   3 +-
 .../translations/zh_CN/vm/memory-model.rst    | 135 ++++++++++++++++++
 2 files changed, 137 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/memory-model.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index dd0b3d4c0ab8..186f85a156c0 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -28,13 +28,14 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    highmem
    frontswap
    hwpoison
+   memory-model
 
 TODOLIST:
 * arch_pgtable_helpers
 * free_page_reporting
 * hmm
 * hugetlbfs_reserv
-* memory-model
+
 * mmu_notifier
 * numa
 * overcommit-accounting
diff --git a/Documentation/translations/zh_CN/vm/memory-model.rst b/Documentation/translations/zh_CN/vm/memory-model.rst
new file mode 100644
index 000000000000..5fe475581cbd
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/memory-model.rst
@@ -0,0 +1,135 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+:Original: Documentation/vm/memory-model.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+============
+物理内存模型
+============
+
+系统中的物理内存可以用不同的方式进行寻址。最简单的情况是，物理内存从地址0开
+始，跨越一个连续的范围，直到最大的地址。然而，这个范围可能包含CPU无法访问的
+小孔隙。那么，在完全不同的地址可能有几个连续的范围。而且，别忘了NUMA，即不
+同的内存库连接到不同的CPU。
+
+Linux使用两种内存模型中的一种对这种多样性进行抽象。FLATMEM和SPARSEM。每
+个架构都定义了它所支持的内存模型，默认的内存模型是什么，以及是否有可能手动
+覆盖该默认值。
+
+所有的内存模型都使用排列在一个或多个数组中的 `struct page` 来跟踪物理页
+帧的状态。
+
+无论选择哪种内存模型，物理页框号（PFN）和相应的 `struct page` 之间都存
+在一对一的映射关系。
+
+每个内存模型都定义了 :c:func:`pfn_to_page` 和 :c:func:`page_to_pfn`
+帮助函数，允许从PFN到 `struct page` 的转换，反之亦然。
+
+FLATMEM
+=======
+
+最简单的内存模型是FLATMEM。这个模型适用于非NUMA系统的连续或大部分连续的
+物理内存。
+
+在FLATMEM内存模型中，有一个全局的 `mem_map` 数组来映射整个物理内存。对
+于大多数架构，孔隙在 `mem_map` 数组中都有条目。与孔洞相对应的 `struct page`
+对象从未被完全初始化。
+
+为了分配 `mem_map` 数组，架构特定的设置代码应该调用free_area_init()函数。
+然而，在调用memblock_free_all()函数之前，映射数组是不能使用的，该函数
+将所有的内存交给页分配器。
+
+一个架构可能会释放 `mem_map` 数组中不包括实际物理页的部分。在这种情况下，特
+定架构的 :c:func:`pfn_valid` 实现应该考虑到 `mem_map` 中的孔隙。
+
+使用FLATMEM，PFN和 `struct page` 之间的转换是直接的。 `PFN - ARCH_PFN_OFFSET`
+是 `mem_map` 数组的一个索引。
+
+`ARCH_PFN_OFFSET` 定义了物理内存起始地址不同于0的系统的第一个页框号。
+
+SPARSEMEM
+=========
+
+SPARSEMEM是Linux中最通用的内存模型，它是唯一支持若干高级功能的内存模型，
+如物理内存的热插拔、非易失性内存设备的替代内存图和较大系统的内存图的延迟
+初始化。
+
+SPARSEMEM模型将物理内存显示为一个部分的集合。一个区段用mem_section结构
+体表示，它包含 `section_mem_map` ，从逻辑上讲，它是一个指向 `struct page`
+阵列的指针。然而，它被存储在一些其他的magic中，以帮助分区管理。区段的大小
+和最大区段数是使用 `SECTION_SIZE_BITS` 和 `MAX_PHYSMEM_BITS` 常量
+来指定的，这两个常量是由每个支持SPARSEMEM的架构定义的。 `MAX_PHYSMEM_BITS`
+是一个架构所支持的物理地址的实际宽度，而 `SECTION_SIZE_BITS` 是一个任
+意的值。
+
+最大的段数表示为 `NR_MEM_SECTIONS` ，定义为
+
+.. math::
+
+   NR\_MEM\_SECTIONS = 2 ^ {(MAX\_PHYSMEM\_BITS - SECTION\_SIZE\_BITS)}
+
+`mem_section` 对象被安排在一个叫做 `mem_sections` 的二维数组中。这个数组的
+大小和位置取决于 `CONFIG_SPARSEM_EXTREME` 和可能的最大段数:
+
+* 当 `CONFIG_SPARSEMEM_EXTREME` 被禁用时， `mem_sections` 数组是静态的，有
+  `NR_MEM_SECTIONS` 行。每一行持有一个 `mem_section` 对象。
+* 当 `CONFIG_SPARSEMEM_EXTREME` 被启用时， `mem_sections` 数组被动态分配。
+  每一行包含价值 `PAGE_SIZE` 的 `mem_section` 对象，行数的计算是为了适应所有的
+  内存区。
+
+架构设置代码应该调用sparse_init()来初始化内存区和内存映射。
+
+通过SPARSEMEM，有两种可能的方式将PFN转换为相应的 `struct page` --"classic sparse"和
+ "sparse vmemmap"。选择是在构建时进行的，它由 `CONFIG_SPARSEMEM_VMEMMAP` 的
+ 值决定。
+
+Classic sparse在page->flags中编码了一个页面的段号，并使用PFN的高位来访问映射该页
+框的段。在一个区段内，PFN是指向页数组的索引。
+
+Sparse vmemmapvmemmap使用虚拟映射的内存映射来优化pfn_to_page和page_to_pfn操
+作。有一个全局的 `struct page *vmemmap` 指针，指向一个虚拟连续的 `struct page`
+对象阵列。PFN是该数组的一个索引，`struct page` 从 `vmemmap` 的偏移量是该页的PFN。
+
+为了使用vmemmap，一个架构必须保留一个虚拟地址的范围，以映射包含内存映射的物理页，并
+确保 `vmemmap`指向该范围。此外，架构应该实现 :c:func:`vmemmap_populate` 方法，
+它将分配物理内存并为虚拟内存映射创建页表。如果一个架构对vmemmap映射没有任何特殊要求，
+它可以使用通用内存管理提供的默认 :c:func:`vmemmap_populate_basepages`。
+
+虚拟映射的内存映射允许将持久性内存设备的 `struct page` 对象存储在这些设备上预先分
+配的存储中。这种存储用vmem_altmap结构表示，最终通过一长串的函数调用传递给
+vmemmap_populate()。vmemmap_populate()实现可以使用 `vmem_altmap` 和
+:c:func:`vmemmap_alloc_block_buf` 助手来分配持久性内存设备上的内存映射。
+
+ZONE_DEVICE
+===========
+`ZONE_DEVICE` 设施建立在 `SPARSEM_VMEMMAP` 之上，为设备驱动识别的物理地址范
+围提供 `struct page` `mem_map` 服务。 `ZONE_DEVICE` 的 "设备" 方面与以下
+事实有关：这些地址范围的页面对象从未被在线标记过，而且必须对设备进行引用，而不仅仅
+是页面，以保持内存被pinned以便使用。 `ZONE_DEVICE` ，通过 :c:func:`devm_memremap_pages` ，
+为给定的pfns范围执行足够的内存热插拔来开启 :c:func:`pfn_to_page`，
+:c:func:`page_to_pfn`, ，和 :c:func:`get_user_pages` 服务。由于页面引
+用计数永远不会低于1，所以页面永远不会被追踪为空闲内存，页面的 `struct list_head lru`
+空间被重新利用，用于向映射该内存的主机设备/驱动程序进行反向引用。
+
+虽然 `SPARSEMEM` 将内存作为一个区段的集合，可以选择收集并合成内存块，但
+`ZONE_DEVICE` 用户需要更小的颗粒度来填充 `mem_map` 。鉴于 `ZONE_DEVICE`
+内存从未被在线标记，因此它的内存范围从未通过sysfs内存热插拔api暴露在内存块边界
+上。这个实现依赖于这种缺乏用户接口的约束，允许子段大小的内存范围被指定给
+:c:func:`arch_add_memory` ，即内存热插拔的上半部分。子段支持允许2MB作为
+:c:func:`devm_memremap_pages` 的跨架构通用对齐颗粒度。
+
+`ZONE_DEVICE` 的用户是:
+
+* pmem: 通过DAX映射将平台持久性内存作为直接I/O目标使用。
+
+* hmm: 用 `->page_fault()` 和 `->page_free()` 事件回调扩展 `ZONE_DEVICE` ，
+  以允许设备驱动程序协调与设备内存相关的内存管理事件，通常是GPU内存。参见/vm/hmm.rst。
+
+* p2pdma: 创建 `struct page` 对象，允许PCI/E拓扑结构中的peer设备协调它们之间的
+  直接DMA操作，即绕过主机内存。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 04/12] docs/zh_CN: add vm mmu_notifier translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (2 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 03/12] docs/zh_CN: add vm memory-model translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-08 15:02   ` Alex Shi
  2022-03-05 16:26 ` [PATCH 05/12] docs/zh_CN: add vm overcommit-accounting translation Yanteng Si
                   ` (7 subsequent siblings)
  11 siblings, 1 reply; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/mmu_notifier.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  3 +-
 .../translations/zh_CN/vm/mmu_notifier.rst    | 97 +++++++++++++++++++
 2 files changed, 98 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/translations/zh_CN/vm/mmu_notifier.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 186f85a156c0..919e879b8167 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -29,14 +29,13 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    frontswap
    hwpoison
    memory-model
+   mmu_notifier
 
 TODOLIST:
 * arch_pgtable_helpers
 * free_page_reporting
 * hmm
 * hugetlbfs_reserv
-
-* mmu_notifier
 * numa
 * overcommit-accounting
 * page_migration
diff --git a/Documentation/translations/zh_CN/vm/mmu_notifier.rst b/Documentation/translations/zh_CN/vm/mmu_notifier.rst
new file mode 100644
index 000000000000..9a85d6acb249
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/mmu_notifier.rst
@@ -0,0 +1,97 @@
+:Original: Documentation/vm/mmu_notifier.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+
+什么时候需要通知内页表锁？
+==========================
+
+当清除一个pte/pmd时，我们可以选择通过在页表锁下（通知版的\*_clear_flush调用
+mmu_notifier_invalidate_range）通知事件。但这种通知并不是在所有情况下都需要的。
+
+对于二级TLB（非CPU TLB），如IOMMU TLB或设备TLB（当设备使用类似ATS/PASID的东西让
+IOMMU走CPU页表来访问进程的虚拟地址空间）。只有两种情况需要在清除pte/pmd时在持有页
+表锁的同时通知这些二级TLB：
+
+  A) 在mmu_notifier_invalidate_range_end()之前，支持页的地址被释放。
+  B) 一个页表项被更新以指向一个新的页面（COW，零页上的写异常，__replace_page()，...）。
+
+情况A很明显，你不想冒风险让设备写到一个现在可能被一些完全不同的任务使用的页面。
+
+情况B更加微妙。为了正确起见，它需要按照以下序列发生:
+
+  - 上页表锁
+  - 清除页表项并通知 ([pmd/pte]p_huge_clear_flush_notify())
+  - 设置页表项以指向新页
+
+如果在设置新的pte/pmd值之前，清除页表项之后没有进行通知，那么你就会破坏设备的C11或
+C++11等内存模型。
+
+考虑以下情况（设备使用类似于ATS/PASID的功能）。
+
+两个地址addrA和addrB，这样|addrA - addrB| >= PAGE_SIZE，我们假设它们是COW的
+写保护（B的其他情况也适用）。
+
+::
+
+ [Time N] --------------------------------------------------------------------
+ CPU-thread-0  {尝试写到addrA}
+ CPU-thread-1  {尝试写到addrB}
+ CPU-thread-2  {}
+ CPU-thread-3  {}
+ DEV-thread-0  {读取addrA并填充设备TLB}
+ DEV-thread-2  {读取addrB并填充设备TLB}
+ [Time N+1] ------------------------------------------------------------------
+ CPU-thread-0  {COW_step0: {mmu_notifier_invalidate_range_start(addrA)}}
+ CPU-thread-1  {COW_step0: {mmu_notifier_invalidate_range_start(addrB)}}
+ CPU-thread-2  {}
+ CPU-thread-3  {}
+ DEV-thread-0  {}
+ DEV-thread-2  {}
+ [Time N+2] ------------------------------------------------------------------
+ CPU-thread-0  {COW_step1: {更新页表以指向addrA的新页}}
+ CPU-thread-1  {COW_step1: {更新页表以指向addrB的新页}}
+ CPU-thread-2  {}
+ CPU-thread-3  {}
+ DEV-thread-0  {}
+ DEV-thread-2  {}
+ [Time N+3] ------------------------------------------------------------------
+ CPU-thread-0  {preempted}
+ CPU-thread-1  {preempted}
+ CPU-thread-2  {写入addrA，这是对新页面的写入}
+ CPU-thread-3  {}
+ DEV-thread-0  {}
+ DEV-thread-2  {}
+ [Time N+3] ------------------------------------------------------------------
+ CPU-thread-0  {preempted}
+ CPU-thread-1  {preempted}
+ CPU-thread-2  {}
+ CPU-thread-3  {写入addrB，这是一个写入新页的过程}
+ DEV-thread-0  {}
+ DEV-thread-2  {}
+ [Time N+4] ------------------------------------------------------------------
+ CPU-thread-0  {preempted}
+ CPU-thread-1  {COW_step3: {mmu_notifier_invalidate_range_end(addrB)}}
+ CPU-thread-2  {}
+ CPU-thread-3  {}
+ DEV-thread-0  {}
+ DEV-thread-2  {}
+ [Time N+5] ------------------------------------------------------------------
+ CPU-thread-0  {preempted}
+ CPU-thread-1  {}
+ CPU-thread-2  {}
+ CPU-thread-3  {}
+ DEV-thread-0  {从旧页中读取addrA}
+ DEV-thread-2  {从新页面读取addrB}
+
+所以在这里，因为在N+2的时候，清空页表项没有和通知一起作废二级TLB，设备在看到addrA的新值之前
+就看到了addrB的新值。这就破坏了设备的总内存序。
+
+当改变一个pte的写保护或指向一个新的具有相同内容的写保护页（KSM）时，将mmu_notifier_invalidate_range
+调用延迟到页表锁外的mmu_notifier_invalidate_range_end()是可以的。即使做页表更新的线程
+在释放页表锁后但在调用mmu_notifier_invalidate_range_end()前被抢占，也是如此。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 05/12] docs/zh_CN: add vm overcommit-accounting translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (3 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 04/12] docs/zh_CN: add vm mmu_notifier translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-08 15:16   ` Alex Shi
  2022-03-05 16:26 ` [PATCH 06/12] docs/zh_CN: add vm page_frags translation Yanteng Si
                   ` (6 subsequent siblings)
  11 siblings, 1 reply; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/overcommit-accounting.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  2 +-
 .../zh_CN/vm/overcommit-accounting.rst        | 86 +++++++++++++++++++
 2 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/overcommit-accounting.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 919e879b8167..2a3a93a4c050 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -30,6 +30,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    hwpoison
    memory-model
    mmu_notifier
+   overcommit-accounting
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -37,7 +38,6 @@ TODOLIST:
 * hmm
 * hugetlbfs_reserv
 * numa
-* overcommit-accounting
 * page_migration
 * page_frags
 * page_owner
diff --git a/Documentation/translations/zh_CN/vm/overcommit-accounting.rst b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst
new file mode 100644
index 000000000000..1e3eae1338cb
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst
@@ -0,0 +1,86 @@
+:Original: Documentation/vm/overcommit.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+
+==============
+Overcommit审计
+==============
+
+Linux内核支持下列overcommit处理模式
+
+0
+	启发式overcommit处理。拒绝明显的地址空间overcommit。用于一个典型的系统。
+	它确保严重的疯狂分配失败，同时允许overcommit以减少swap的使用。在这种模式下，
+	允许root分配稍多的内存。这是默认的。
+1
+	总是overcommit。适用于一些科学应用。经典的例子是使用稀疏数组的代码，只是依赖
+	几乎完全由零页组成的虚拟内存
+
+2
+	不overcommit。系统提交的总地址空间不允许超过swap+一个可配置的物理RAM的数量
+	（默认为50%）。根据你使用的数量，在大多数情况下，这意味着一个进程在访问页面时
+	不会被杀死，但会在内存分配上收到相应的错误。
+
+	对于那些想保证他们的内存分配在未来可用而又不需要初始化每一个页面的应用程序来说
+	是很有用的。
+
+overcommit策略是通过sysctl  `vm.overcommit_memory` 设置的。
+
+可以通过 `vm.overcommit_ratio` （百分比）或 `vm.overcommit_kbytes` （绝对值）
+来设置超限数量。这些只有在 `vm.overcommit_memory` 被设置为2时才有效果。
+
+在 ``/proc/meminfo`` 中可以分别以CommitLimit和Committed_AS的形式查看当前
+的overcommit和提交量。
+
+陷阱
+====
+
+C语言的堆栈增长是一个隐含的mremap。如果你想得到绝对的保证，并在接近边缘的地方运行，
+你 **必须** 为你认为你需要的最大尺寸的堆栈进行mmap。对于典型的堆栈使用来说，这并
+不重要，但如果你真的非常关心的话，这就是一个值得关注的案例。
+
+
+在模式2中，MAP_NORESERVE标志被忽略。
+
+
+它是如何工作的
+==============
+
+overcommit是基于以下规则
+
+For a file backed map
+	| SHARED or READ-only	-	0 cost (该文件是映射而不是交换)
+	| PRIVATE WRITABLE	-	每个实例的映射大小
+
+For an anonymous or ``/dev/zero`` map
+	| SHARED			-	映射的大小
+	| PRIVATE READ-only	-	0 cost (但作用不大)
+	| PRIVATE WRITABLE	-	每个实例的映射大小
+
+Additional accounting
+	| 通过mmap制作可写副本的页面
+	| 从同一池中提取的shmfs内存
+
+状态
+====
+
+*	我们核算mmap内存映射
+*	我们核算mprotect在提交中的变化
+*	我们核算mremap的大小变化
+*	我们的审计 brk
+*	审计munmap
+*	我们在/proc中报告commit 状态
+*	核对并检查分叉的情况
+*	审查堆栈处理/执行中的构建
+*	叙述SHMfs的情况
+*	实现实际限制的执行
+
+待续
+====
+*	帐户trace页（这很难）。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 06/12] docs/zh_CN: add vm page_frags translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (4 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 05/12] docs/zh_CN: add vm overcommit-accounting translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-05 16:26 ` [PATCH 07/12] docs/zh_CN: add vm page_owner translation Yanteng Si
                   ` (5 subsequent siblings)
  11 siblings, 0 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/page_frags.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  2 +-
 .../translations/zh_CN/vm/page_frags.rst      | 38 +++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/page_frags.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 2a3a93a4c050..6e676b71607e 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -31,6 +31,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    memory-model
    mmu_notifier
    overcommit-accounting
+   page_frags
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -39,7 +40,6 @@ TODOLIST:
 * hugetlbfs_reserv
 * numa
 * page_migration
-* page_frags
 * page_owner
 * page_table_check
 * remap_file_pages
diff --git a/Documentation/translations/zh_CN/vm/page_frags.rst b/Documentation/translations/zh_CN/vm/page_frags.rst
new file mode 100644
index 000000000000..7d974d61f102
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/page_frags.rst
@@ -0,0 +1,38 @@
+:Original: Documentation/vm/page_frag.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+========
+页面片段
+========
+
+一个页面片段是一个任意长度的任意偏移的内存区域，它位于一个0或更高阶的复合页面中。
+该页中的多个碎片在该页的引用计数器中被单独计算。
+
+page_frag函数，page_frag_alloc和page_frag_free，为页面片段提供了一个简单
+的分配框架。这被网络堆栈和网络设备驱动使用，以提供一个内存的支持区域，作为
+sk_buff->head使用，或者用于skb_shared_info的 "frags "部分。
+
+为了使用页面片段API，需要一个支持页面片段的缓冲区。这为碎片分配提供了一个中心点，
+并允许多个调用使用一个缓存的页面。这样做的好处是可以避免对get_page的多次调用，
+这在分配时可能会很昂贵。然而，由于这种缓存的性质，要求任何对缓存的调用都要受到每
+个CPU的限制，或者每个CPU的限制，并在执行碎片分配时强制禁止中断。
+
+网络堆栈在每个CPU使用两个独立的缓存来处理碎片分配。netdev_alloc_cache被使用
+netdev_alloc_frag和__netdev_alloc_skb调用的调用者使用。napi_alloc_cache
+被调用__napi_alloc_frag和__napi_alloc_skb的人使用。这两个调用的主要区别是
+它们可能被调用的环境。“netdev” 前缀的函数可以在任何上下文中使用，因为这些函数
+将禁用中断，而 ”napi“ 前缀的函数只可以在softirq上下文中使用。
+
+许多网络设备驱动程序使用类似的方法来分配页面片段，但页面片段是在环或描述符级别上
+缓存的。为了实现这些情况，有必要提供一种拆解页面缓存的通用方法。出于这个原因，
+__page_frag_cache_drain被实现了。它允许通过一次调用从一个页面释放多个引用。
+这样做的好处是，它允许清理被添加到一个页面的多个引用，以避免每次分配都调用
+get_page。
+
+Alexander Duyck，2016年11月29日。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 07/12] docs/zh_CN: add vm page_owner translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (5 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 06/12] docs/zh_CN: add vm page_frags translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-05 16:26 ` [PATCH 08/12] docs/zh_CN: add vm page_table_check translation Yanteng Si
                   ` (4 subsequent siblings)
  11 siblings, 0 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/page_owner.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |   2 +-
 .../translations/zh_CN/vm/page_owner.rst      | 116 ++++++++++++++++++
 2 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/page_owner.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 6e676b71607e..b706c5ceff0c 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -32,6 +32,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    mmu_notifier
    overcommit-accounting
    page_frags
+   page_owner
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -40,7 +41,6 @@ TODOLIST:
 * hugetlbfs_reserv
 * numa
 * page_migration
-* page_owner
 * page_table_check
 * remap_file_pages
 * slub
diff --git a/Documentation/translations/zh_CN/vm/page_owner.rst b/Documentation/translations/zh_CN/vm/page_owner.rst
new file mode 100644
index 000000000000..2577f544c7a9
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/page_owner.rst
@@ -0,0 +1,116 @@
+:Original: Documentation/vm/page_owner.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+================================
+page owner: 跟踪谁分配的每个页面
+================================
+
+概述
+====
+
+page owner是用来追踪谁分配的每一个页面。它可以用来调试内存泄漏或找到内存占用者。
+当分配发生时，有关分配的信息，如调用堆栈和页面的顺序被存储到每个页面的特定存储中。
+当我们需要了解所有页面的状态时，我们可以获得并分析这些信息。
+
+尽管我们已经有了追踪页面分配/释放的tracepoint，但用它来分析谁分配的每个页面是
+相当复杂的。我们需要扩大跟踪缓冲区，以防止在用户空间程序启动前出现重叠。而且，启
+动的程序会不断地将跟踪缓冲区转出，供以后分析，这将会改变系统的行为，会产生更多的
+可能性，而不是仅仅保留在内存中，所以不利于调试。
+
+页面所有者也可以用于各种目的。例如，可以通过每个页面的gfp标志信息获得精确的碎片
+统计。如果启用了page owner，它就已经实现并激活了。我们非常欢迎其他用途。
+
+page owner在默认情况下是禁用的。所以，如果你想使用它，你需要在你的启动cmdline
+中加入"page_owner=on"。如果内核是用page owner构建的，并且由于没有启用启动
+选项而在运行时禁用page owner，那么运行时的开销是很小的。如果在运行时禁用，它不
+需要内存来存储所有者信息，所以没有运行时内存开销。而且，页面所有者在页面分配器的
+热路径中只插入了两个不可能的分支，如果不启用，那么分配就会像没有页面所有者的内核
+一样进行。这两个不可能的分支应该不会影响到分配的性能，特别是在静态键跳转标签修补
+功能可用的情况下。以下是由于这个功能而导致的内核代码大小的变化。
+
+- 没有page owner::
+
+   text    data     bss     dec     hex filename
+   48392   2333     644   51369    c8a9 mm/page_alloc.o
+
+- 有page owner::
+
+   text    data     bss     dec     hex filename
+   48800   2445     644   51889    cab1 mm/page_alloc.o
+   6662     108      29    6799    1a8f mm/page_owner.o
+   1025       8       8    1041     411 mm/page_ext.o
+
+虽然总共增加了8KB的代码，但page_alloc.o增加了520字节，其中不到一半是在hotpath
+中。构建带有page owner的内核，并在需要时打开它，将是调试内核内存问题的最佳选择。
+
+有一个问题是由实现细节引起的。页所有者将信息存储到struct page扩展的内存中。这
+个内存的初始化时间比稀疏内存系统中的页面分配器启动的时间要晚一些，所以，在初始化
+之前，许多页面可以被分配，但它们没有所有者信息。为了解决这个问题，这些早期分配的
+页面在初始化阶段被调查并标记为分配。虽然这并不意味着它们有正确的所有者信息，但至
+少，我们可以更准确地判断该页是否被分配。在2GB内存的x86-64虚拟机盒子上，有13343
+个早期分配的页面被捕捉和标记，尽管它们大部分是由结构页扩展功能分配的。总之，在这
+之后，没有任何页面处于未追踪状态。
+
+使用方法
+========
+
+1) 构建用户空间的帮助::
+
+	cd tools/vm
+	make page_owner_sort
+
+2) 启用page owner: 添加 "page_owner=on" 到 boot cmdline.
+
+3) 做你想调试的工作。
+
+4) 分析来自页面所有者的信息::
+
+	cat /sys/kernel/debug/page_owner > page_owner_full.txt
+	./page_owner_sort page_owner_full.txt sorted_page_owner.txt
+
+   ``page_owner_full.txt`` 的一般输出情况如下(输出情况无翻译价值)::
+
+	Page allocated via order XXX, ...
+	PFN XXX ...
+	// Detailed stack
+
+	Page allocated via order XXX, ...
+	PFN XXX ...
+	// Detailed stack
+
+   ``page_owner_sort`` 工具忽略了 ``PFN`` 行，将剩余的行放在buf中，使用regexp提
+   取页序值，计算buf的次数和页数，最后根据参数进行排序。
+
+   在 ``sorted_page_owner.txt`` 中可以看到关于谁分配了每个页面的结果。一般输出::
+
+	XXX times, XXX pages:
+	Page allocated via order XXX, ...
+	// Detailed stack
+
+   默认情况下， ``page_owner_sort`` 是根据buf的时间来排序的。如果你想
+   按buf的页数排序，请使用-m参数。详细的参数是:
+
+   基本函数:
+
+	Sort:
+		-a		按内存分配时间排序
+		-m		按总内存排序
+		-p		按pid排序。
+		-P		按tgid排序。
+		-r		按内存释放时间排序。
+		-s		按堆栈跟踪排序。
+		-t		按时间排序（默认）。
+
+   其它函数:
+
+	Cull:
+		-c		通过比较堆栈跟踪而不是总块来进行剔除。
+
+	Filter:
+		-f		过滤掉内存已被释放的块的信息。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 08/12] docs/zh_CN: add vm page_table_check translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (6 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 07/12] docs/zh_CN: add vm page_owner translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-05 16:26 ` [PATCH 09/12] docs/zh_CN: add vm remap_file_pages translation Yanteng Si
                   ` (3 subsequent siblings)
  11 siblings, 0 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/page_table_check.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  2 +-
 .../zh_CN/vm/page_table_check.rst             | 56 +++++++++++++++++++
 2 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/page_table_check.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index b706c5ceff0c..33a04a623608 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -33,6 +33,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    overcommit-accounting
    page_frags
    page_owner
+   page_table_check
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -41,7 +42,6 @@ TODOLIST:
 * hugetlbfs_reserv
 * numa
 * page_migration
-* page_table_check
 * remap_file_pages
 * slub
 * split_page_table_lock
diff --git a/Documentation/translations/zh_CN/vm/page_table_check.rst b/Documentation/translations/zh_CN/vm/page_table_check.rst
new file mode 100644
index 000000000000..a29fc1b360e6
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/page_table_check.rst
@@ -0,0 +1,56 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+:Original: Documentation/vm/page_table_check.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+========
+页表检查
+========
+
+概述
+====
+
+页表检查允许通过确保防止某些类型的内存损坏来强化内核。
+
+当新的页面可以从用户空间访问时，页表检查通过将它们的页表项（PTEs PMD等）添加到页表中来执行额外
+的验证。
+
+在检测到损坏的情况下，内核会被崩溃。页表检查有一个小的性能和内存开销。因此，它在默认情况下是禁用
+的，但是在额外的加固超过性能成本的系统上，可以选择启用。另外，由于页表检查是同步的，它可以帮助调
+试双映射内存损坏问题，在错误的映射发生时崩溃内核，而不是在内存损坏错误发生后内核崩溃。
+
+双重映射检测逻辑
+================
+
++-------------------+-------------------+-------------------+------------------+
+| Current Mapping   | New mapping       | Permissions       | Rule             |
++===================+===================+===================+==================+
+| Anonymous         | Anonymous         | Read              | Allow            |
++-------------------+-------------------+-------------------+------------------+
+| Anonymous         | Anonymous         | Read / Write      | Prohibit         |
++-------------------+-------------------+-------------------+------------------+
+| Anonymous         | Named             | Any               | Prohibit         |
++-------------------+-------------------+-------------------+------------------+
+| Named             | Anonymous         | Any               | Prohibit         |
++-------------------+-------------------+-------------------+------------------+
+| Named             | Named             | Any               | Allow            |
++-------------------+-------------------+-------------------+------------------+
+
+启用页表检查
+============
+
+用以下方法构建内核:
+
+- PAGE_TABLE_CHECK=y
+  注意，它只能在ARCH_SUPPORTS_PAGE_TABLE_CHECK可用的平台上启用。
+
+- 使用 "page_table_check=on" 内核参数启动。
+
+可以选择用PAGE_TABLE_CHECK_ENFORCED来构建内核，以便在没有额外的内核参数的情况下获得页表
+支持。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 09/12] docs/zh_CN: add vm remap_file_pages translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (7 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 08/12] docs/zh_CN: add vm page_table_check translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-05 16:26 ` [PATCH 10/12] docs/zh_CN: add vm split_page_table_lock translation Yanteng Si
                   ` (2 subsequent siblings)
  11 siblings, 0 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/remap_file_pages.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  2 +-
 .../zh_CN/vm/remap_file_pages.rst             | 32 +++++++++++++++++++
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/remap_file_pages.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 33a04a623608..6d804be1b9d1 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -34,6 +34,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    page_frags
    page_owner
    page_table_check
+   remap_file_pages
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -42,7 +43,6 @@ TODOLIST:
 * hugetlbfs_reserv
 * numa
 * page_migration
-* remap_file_pages
 * slub
 * split_page_table_lock
 * transhuge
diff --git a/Documentation/translations/zh_CN/vm/remap_file_pages.rst b/Documentation/translations/zh_CN/vm/remap_file_pages.rst
new file mode 100644
index 000000000000..4291c600d22a
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/remap_file_pages.rst
@@ -0,0 +1,32 @@
+:Original: Documentation/vm/remap_file_pages.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+==============================
+remap_file_pages()系统调用
+==============================
+
+remap_file_pages()系统调用被用来创建一个非线性映射，也就是说，在这个映射中，
+文件的页面被无序映射到内存中。使用remap_file_pages()比重复调用mmap(2)的好
+处是，前者不需要内核创建额外的VMA（虚拟内存区）数据结构。
+
+支持非线性映射需要在内核虚拟内存子系统中编写大量的non-trivial的代码，包括热
+路径。另外，为了使非线性映射工作，内核需要一种方法来区分正常的页表项和带有文件
+偏移的项（pte_file）。内核为达到这个目的在PTE中保留了标志。PTE标志是稀缺资
+源，特别是在某些CPU架构上。如果能腾出这个标志用于其他用途就更好了。
+
+幸运的是，在生活中并没有很多remap_file_pages()的用户。只知道一个企业的RDBMS
+实现在32位系统上使用这个系统调用来映射比32位虚拟地址空间线性尺寸更大的文件。
+由于64位系统的广泛使用，这种使用情况已经不重要了。
+
+syscall被废弃了，现在用一个模拟来代替它。仿真会创建新的VMA，而不是非线性映射。
+对于remap_file_pages()的少数用户来说，它的工作速度会变慢，但ABI被保留了。
+
+仿真的一个副作用（除了性能之外）是，由于额外的VMA，用户可以更容易达到
+vm.max_map_count的限制。关于限制的更多细节，请参见DEFAULT_MAX_MAP_COUNT
+的注释。
\ No newline at end of file
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 10/12] docs/zh_CN: add vm split_page_table_lock translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (8 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 09/12] docs/zh_CN: add vm remap_file_pages translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-05 16:26 ` [PATCH 11/12] docs/zh_CN: add vm z3fold translation Yanteng Si
  2022-03-05 16:26 ` [PATCH 12/12] docs/zh_CN: add vm zsmalloc translation Yanteng Si
  11 siblings, 0 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/split_page_table_lock.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  2 +-
 .../zh_CN/vm/split_page_table_lock.rst        | 96 +++++++++++++++++++
 2 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/split_page_table_lock.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 6d804be1b9d1..343a82b56ec2 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -35,6 +35,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    page_owner
    page_table_check
    remap_file_pages
+   split_page_table_lock
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -44,7 +45,6 @@ TODOLIST:
 * numa
 * page_migration
 * slub
-* split_page_table_lock
 * transhuge
 * unevictable-lru
 * vmalloced-kernel-stacks
diff --git a/Documentation/translations/zh_CN/vm/split_page_table_lock.rst b/Documentation/translations/zh_CN/vm/split_page_table_lock.rst
new file mode 100644
index 000000000000..c2610a69676e
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/split_page_table_lock.rst
@@ -0,0 +1,96 @@
+:Original: Documentation/vm/split_page_table_lock.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+=================================
+分页表锁（split page table lock）
+=================================
+
+最初，mm->page_table_lock spinlock保护了mm_struct的所有页表。但是这种方
+法导致了多线程应用程序的缺页异常可扩展性差，因为对锁的争夺很激烈。为了提高可扩
+展性，我们引入了分页表锁。
+
+有了分页表锁，我们就有了单独的每张表锁来顺序化对表的访问。目前，我们对PTE和
+PMD表使用分页锁。对高层表的访问由mm->page_table_lock保护。
+
+有一些辅助工具来锁定/解锁一个表和其他访问器函数:
+
+ - pte_offset_map_lock()
+	映射pte并获取PTE表锁，返回所取锁的指针；
+ - pte_unmap_unlock()
+	解锁和解映射PTE表；
+ - pte_alloc_map_lock()
+	如果需要的话，分配PTE表并获取锁，如果分配失败，返回已获取的锁的指针
+	或NULL；
+ - pte_lockptr()
+	返回指向PTE表锁的指针；
+ - pmd_lock()
+	取得PMD表锁，返回所取锁的指针。
+ - pmd_lockptr()
+	返回指向PMD表锁的指针；
+
+如果CONFIG_SPLIT_PTLOCK_CPUS（通常为4）小于或等于NR_CPUS，则在编译
+时启用PTE表的分页表锁。如果分页锁被禁用，所有的表都由mm->page_table_lock
+来保护。
+
+如果PMD表启用了分页锁，并且架构支持它，那么PMD表的分页锁就会被启用（见
+下文）。
+
+Hugetlb 和分页表锁
+==================
+
+Hugetlb可以支持多种页面大小。我们只对PMD级别使用分割锁，但不对PUD使用。
+
+Hugetlb特定的辅助函数:
+
+ - huge_pte_lock()
+	对PMD_SIZE页面采取pmd分割锁，否则mm->page_table_lock；
+ - huge_pte_lockptr()
+	返回指向表锁的指针。
+
+架构对分页表锁的支持
+====================
+
+没有必要特别启用PTE分页表锁：所有需要的东西都由pgtable_pte_page_ctor()
+和pgtable_pte_page_dtor()完成，它们必须在PTE表分配/释放时被调用。
+
+确保架构不使用slab分配器来分配页表：slab使用page->slab_cache来分配其页
+面。这个区域与page->ptl共享存储。
+
+PMD分页锁只有在你有两个以上的页表级别时才有意义。
+
+启用PMD分页锁需要在PMD表分配时调用pgtable_pmd_page_ctor()，在释放时调
+用pgtable_pmd_page_dtor()。
+
+分配通常发生在pmd_alloc_one()中，释放发生在pmd_free()和pmd_free_tlb()
+中，但要确保覆盖所有的PMD表分配/释放路径：即X86_PAE在pgd_alloc()中预先
+分配一些PMD。
+
+一切就绪后，你可以设置CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK。
+
+注意：pgtable_pte_page_ctor()和pgtable_pmd_page_ctor()可能失败--必
+须正确处理。
+
+page->ptl
+=========
+
+page->ptl用于访问分割页表锁，其中'page'是包含该表的页面struct page。它
+与page->private（以及union中的其他几个字段）共享存储。
+
+为了避免增加struct page的大小并获得最佳性能，我们使用了一个技巧:
+
+ - 如果spinlock_t适合于long，我们使用page->ptr作为spinlock，这样我们
+   就可以避免间接访问并节省一个缓存行。
+ - 如果spinlock_t的大小大于long的大小，我们使用page->ptl作为spinlock_t
+   的指针并动态分配它。这允许在启用DEBUG_SPINLOCK或DEBUG_LOCK_ALLOC的
+   情况下使用分页锁，但由于间接访问而多花了一个缓存行。
+
+PTE表的spinlock_t分配在pgtable_pte_page_ctor()中，PMD表的spinlock_t
+分配在pgtable_pmd_page_ctor()中。
+
+请不要直接访问page->ptl - -使用适当的辅助函数。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 11/12] docs/zh_CN: add vm z3fold translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (9 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 10/12] docs/zh_CN: add vm split_page_table_lock translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  2022-03-05 16:26 ` [PATCH 12/12] docs/zh_CN: add vm zsmalloc translation Yanteng Si
  11 siblings, 0 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/z3fold.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  2 +-
 .../translations/zh_CN/vm/z3fold.rst          | 31 +++++++++++++++++++
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/z3fold.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index 343a82b56ec2..fb9a6aaf2b57 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -36,6 +36,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    page_table_check
    remap_file_pages
    split_page_table_lock
+   z3fold
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -48,5 +49,4 @@ TODOLIST:
 * transhuge
 * unevictable-lru
 * vmalloced-kernel-stacks
-* z3fold
 * zsmalloc
diff --git a/Documentation/translations/zh_CN/vm/z3fold.rst b/Documentation/translations/zh_CN/vm/z3fold.rst
new file mode 100644
index 000000000000..5fe0f386c74e
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/z3fold.rst
@@ -0,0 +1,31 @@
+:Original: Documentation/vm/z3fold.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+======
+z3fold
+======
+
+z3fold是一个专门用于存储压缩页的分配器。它被设计为每个物理页最多可以存储三个压缩页。
+它是zbud的衍生物，允许更高的压缩率，保持其前辈的简单性和确定性。
+
+z3fold和zbud的主要区别是:
+
+* 与zbud不同的是，z3fold允许最大的PAGE_SIZE分配。
+* z3fold在其页面中最多可以容纳3个压缩页面
+* z3fold本身没有输出任何API，因此打算通过zpool的API来使用
+
+为了保持确定性和简单性，z3fold，就像zbud一样，总是在每页存储一个整数的压缩页，但是
+它最多可以存储3页，不像zbud最多可以存储2页。因此压缩率达到2.7倍左右，而zbud的压缩
+率是1.7倍左右。
+
+不像zbud（但也像zsmalloc），z3fold_alloc()不返回一个可重复引用的指针。相反，它
+返回一个无符号长句柄，它编码了被分配对象的实际位置。
+
+保持有效的压缩率接近于zsmalloc，z3fold不依赖于MMU的启用，并提供更可预测的回收行
+为，这使得它更适合于小型和响应关键的系统。
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 12/12] docs/zh_CN: add vm zsmalloc translation
  2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
                   ` (10 preceding siblings ...)
  2022-03-05 16:26 ` [PATCH 11/12] docs/zh_CN: add vm z3fold translation Yanteng Si
@ 2022-03-05 16:26 ` Yanteng Si
  11 siblings, 0 replies; 21+ messages in thread
From: Yanteng Si @ 2022-03-05 16:26 UTC (permalink / raw)
  To: corbet, alexs, seakeel
  Cc: Yanteng Si, chenhuacai, jiaxun.yang, linux-doc, siyanteng01

Translate .../vm/zsmalloc.rst into Chinese.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
---
 Documentation/translations/zh_CN/vm/index.rst |  2 +-
 .../translations/zh_CN/vm/zsmalloc.rst        | 78 +++++++++++++++++++
 2 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/zh_CN/vm/zsmalloc.rst

diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
index fb9a6aaf2b57..efd298865c3f 100644
--- a/Documentation/translations/zh_CN/vm/index.rst
+++ b/Documentation/translations/zh_CN/vm/index.rst
@@ -37,6 +37,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
    remap_file_pages
    split_page_table_lock
    z3fold
+   zsmalloc
 
 TODOLIST:
 * arch_pgtable_helpers
@@ -49,4 +50,3 @@ TODOLIST:
 * transhuge
 * unevictable-lru
 * vmalloced-kernel-stacks
-* zsmalloc
diff --git a/Documentation/translations/zh_CN/vm/zsmalloc.rst b/Documentation/translations/zh_CN/vm/zsmalloc.rst
new file mode 100644
index 000000000000..29e9c70a8eb6
--- /dev/null
+++ b/Documentation/translations/zh_CN/vm/zsmalloc.rst
@@ -0,0 +1,78 @@
+:Original: Documentation/vm/zs_malloc.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+========
+zsmalloc
+========
+
+这个分配器是为与zram一起使用而设计的。因此，该分配器应该在低内存条件下工作良好。特别是，
+它从未尝试过higher order页面的分配，这在内存压力下很可能会失败。另一方面，如果我们只
+是使用单（0-order）页，它将遭受非常高的碎片化 - 任何大小为PAGE_SIZE/2或更大的对象将
+占据整个页面。这是其前身（xvmalloc）的主要问题之一。
+
+为了克服这些问题，zsmalloc分配了一堆0-order页面，并使用各种"struct page"字段将它
+们链接起来。这些链接的页面作为一个单一的higher order页面，即一个对象可以跨越0-order
+页面的边界。代码将这些链接的页面作为一个实体，称为zspage。
+
+为了简单起见，zsmalloc只能分配大小不超过PAGE_SIZE的对象，因为这满足了所有当前用户的
+要求（在最坏的情况下，页面是不可压缩的，因此以"原样"即未压缩的形式存储）。对于大于这
+个大小的分配请求，会返回失败（见zs_malloc）。
+
+此外，zs_malloc()并不返回一个可重复引用的指针。相反，它返回一个不透明的句柄（无符号
+长），它编码了被分配对象的实际位置。这种间接性的原因是zsmalloc并不保持zspages的永久
+映射，因为这在32位系统上会导致问题，因为内核空间映射的VA区域非常小。因此，在使用分配
+的内存之前，对象必须使用zs_map_object()进行映射以获得一个可用的指针，随后使用
+zs_unmap_object()解除映射。
+
+stat
+====
+
+通过CONFIG_ZSMALLOC_STAT，我们可以通过 ``/sys/kernel/debug/zsmalloc/<user name>``
+看到zsmalloc内部信息。下面是一个统计输出的例子。::
+
+ # cat /sys/kernel/debug/zsmalloc/zram0/classes
+
+ class  size almost_full almost_empty obj_allocated   obj_used pages_used pages_per_zspage
+    ...
+    ...
+     9   176           0            1           186        129          8                4
+    10   192           1            0          2880       2872        135                3
+    11   208           0            1           819        795         42                2
+    12   224           0            1           219        159         12                4
+    ...
+    ...
+
+
+class
+	索引
+size
+	zspage存储对象大小
+almost_empty
+	ZS_ALMOST_EMPTY zspage的数量（见下文）。
+almost_full
+	ZS_ALMOST_FULL zspage的数量(见下图)
+obj_allocated
+	已分配对象的数量
+obj_used
+	分配给用户的对象的数量
+pages_used
+	为该类分配的页数
+pages_per_zspage
+	组成一个zspage的0-order页面的数量
+
+当n <= N / f时，我们将一个zspage分配给ZS_ALMOST_EMPTYfullness组，其中
+
+* n = 已分配对象的数量
+* N = zspage可以存储的对象总数
+* f = fullness_threshold_frac(即，目前是4个)
+
+同样地，我们将zspage分配给:
+
+* ZS_ALMOST_FULL  when n > N / f
+* ZS_EMPTY        when n == 0
+* ZS_FULL         when n == N
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH 01/12] docs/zh_CN: add vm frontswap translation
  2022-03-05 16:26 ` [PATCH 01/12] docs/zh_CN: add vm frontswap translation Yanteng Si
@ 2022-03-08 11:49   ` Alex Shi
  0 siblings, 0 replies; 21+ messages in thread
From: Alex Shi @ 2022-03-08 11:49 UTC (permalink / raw)
  To: Yanteng Si
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

On Sun, Mar 6, 2022 at 12:24 AM Yanteng Si <siyanteng01@gmail.com> wrote:
>
> Translate .../vm/_free_page_reporting.rst into Chinese.
>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

Reviewed-by: Alex Shi <alexs@kernel.org>

> ---
>  .../translations/zh_CN/vm/frontswap.rst       | 196 ++++++++++++++++++
>  Documentation/translations/zh_CN/vm/index.rst |   2 +-
>  2 files changed, 197 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/translations/zh_CN/vm/frontswap.rst
>
> diff --git a/Documentation/translations/zh_CN/vm/frontswap.rst b/Documentation/translations/zh_CN/vm/frontswap.rst
> new file mode 100644
> index 000000000000..3eb07870e2ef
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/vm/frontswap.rst
> @@ -0,0 +1,196 @@
> +:Original: Documentation/vm/_free_page_reporting.rst
> +
> +:翻译:
> +
> + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> +
> +:校译:
> +
> +=========
> +Frontswap
> +=========
> +
> +Frontswap为交换页提供了一个 “transcendent memory” 的接口。在一些环境中，由
> +于交换页被保存在RAM（或类似RAM的设备）中，而不是交换磁盘，因此可以获得巨大的性能
> +节省（提高）。
> +
> +.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
> +
> +Frontswap之所以这么命名，是因为它可以被认为是与swap设备的“back”存储相反。存
> +储器被认为是一个同步并发安全的面向页面的“伪RAM设备”，符合transcendent memory
> +（如Xen的“tmem”，或内核内压缩内存，又称“zcache”，或未来的类似RAM的设备）的要
> +求；这个伪RAM设备不能被内核直接访问或寻址，其大小未知且可能随时间变化。驱动程序通过
> +调用frontswap_register_ops将自己与frontswap链接起来，以适当地设置frontswap_ops
> +的功能，它提供的功能必须符合某些策略，如下所示:
> +
> +一个 “init” 将设备准备好接收与指定的交换设备编号（又称“类型”）相关的frontswap
> +交换页。一个 “store” 将把该页复制到transcendent memory，并与该页的类型和偏移
> +量相关联。一个 “load” 将把该页，如果找到的话，从transcendent memory复制到内核
> +内存，但不会从transcendent memory中删除该页。一个 “invalidate_page” 将从
> +transcendent memory中删除该页，一个 “invalidate_area” 将删除所有与交换类型
> +相关的页（例如，像swapoff）并通知 “device” 拒绝进一步存储该交换类型。
> +
> +一旦一个页面被成功存储，在该页面上的匹配加载通常会成功。因此，当内核发现自己处于需
> +要交换页面的情况时，它首先尝试使用frontswap。如果存储的结果是成功的，那么数据就已
> +经成功的保存到了transcendent memory中，并且避免了磁盘写入，如果后来再读回数据，
> +也避免了磁盘读取。如果存储返回失败，transcendent memory已经拒绝了该数据，且该页
> +可以像往常一样被写入交换空间。
> +
> +请注意，如果一个页面被存储，而该页面已经存在于transcendent memory中（一个 “重复”
> +的存储），要么存储成功，数据被覆盖，要么存储失败，该页面被废止。这确保了旧的数据永远
> +不会从frontswap中获得。
> +
> +如果配置正确，对frontswap的监控是通过 `/sys/kernel/debug/frontswap` 目录下的
> +debugfs完成的。frontswap的有效性可以通过以下方式测量（在所有交换设备中）:
> +
> +``failed_stores``
> +       有多少次存储的尝试是失败的
> +
> +``loads``
> +       尝试了多少次加载（应该全部成功）
> +
> +``succ_stores``
> +       有多少次存储的尝试是成功的
> +
> +``invalidates``
> +       尝试了多少次作废
> +
> +后台实现可以提供额外的指标。
> +
> +经常问到的问题
> +==============
> +
> +* 价值在哪里?
> +
> +当一个工作负载开始交换时，性能就会下降。Frontswap通过提供一个干净的、动态的接口来
> +读取和写入交换页到 “transcendent memory”，从而大大增加了许多这样的工作负载的性
> +能，否则内核是无法直接寻址的。当数据被转换为不同的形式和大小（比如压缩）或者被秘密
> +移动（对于一些类似RAM的设备来说，这可能对写平衡很有用）时，这个接口是理想的。交换
> +页（和被驱逐的页面缓存页）是这种比RAM慢但比磁盘快得多的“伪RAM设备”的一大用途。
> +
> +Frontswap对内核的影响相当小，为各种系统配置中更动态、更灵活的RAM利用提供了巨大的
> +灵活性：
> +
> +在单一内核的情况下，又称“zcache”，页面被压缩并存储在本地内存中，从而增加了可以安
> +全保存在RAM中的匿名页面总数。Zcache本质上是用压缩/解压缩的CPU周期换取更好的内存利
> +用率。Benchmarks测试显示，当内存压力较低时，几乎没有影响，而在高内存压力下的一些
> +工作负载上，则有明显的性能改善（25%以上）。
> +
> +“RAMster” 在zcache的基础上增加了对集群系统的 “peer-to-peer” transcendent memory
> +的支持。Frontswap页面像zcache一样被本地压缩，但随后被“remotified” 到另一个系
> +统的RAM。这使得RAM可以根据需要动态地来回负载平衡，也就是说，当系统A超载时，它可以
> +交换到系统B，反之亦然。RAMster也可以被配置成一个内存服务器，因此集群中的许多服务器
> +可以根据需要动态地交换到配置有大量内存的单一服务器上......而不需要预先配置每个客户
> +有多少内存可用
> +
> +在虚拟情况下，虚拟化的全部意义在于统计地将物理资源在多个虚拟机的不同需求之间进行复
> +用。对于RAM来说，这真的很难做到，而且在不改变内核的情况下，要做好这一点的努力基本上
> +是失败的（除了一些广为人知的特殊情况下的工作负载）。具体来说，Xen Transcendent Memory
> +后端允许管理器拥有的RAM “fallow”，不仅可以在多个虚拟机之间进行“time-shared”，
> +而且页面可以被压缩和重复利用，以优化RAM的利用率。当客户操作系统被诱导交出未充分利用
> +的RAM时（如 “selfballooning”），突然出现的意外内存压力可能会导致交换；frontswap
> +允许这些页面被交换到管理器RAM中或从管理器RAM中交换（如果整体主机系统内存条件允许），
> +从而减轻计划外交换可能带来的可怕的性能影响。
> +
> +一个KVM的实现正在进行中，并且已经被RFC'ed到lkml。而且，利用frontswap，对NVM作为
> +内存扩展技术的调查也在进行中。
> +
> +* 当然，在某些情况下可能有性能上的优势，但frontswap的空间/时间开销是多少？
> +
> +如果 CONFIG_FRONTSWAP 被禁用，每个 frontswap 钩子都会编译成空，唯一的开销是每
> +个 swapon'ed swap 设备的几个额外字节。如果 CONFIG_FRONTSWAP 被启用，但没有
> +frontswap的 “backend” 寄存器，每读或写一个交换页就会有一个额外的全局变量，而不
> +是零。如果 CONFIG_FRONTSWAP 被启用，并且有一个frontswap的backend寄存器，并且
> +后端每次 “store” 请求都失败（即尽管声称可能，但没有提供内存），CPU 的开销仍然可以
> +忽略不计 - 因为每次frontswap失败都是在交换页写到磁盘之前，系统很可能是 I/O 绑定
> +的，无论如何使用一小部分的 CPU 都是不相关的。
> +
> +至于空间，如果CONFIG_FRONTSWAP被启用，并且有一个frontswap的backend注册，那么
> +每个交换设备的每个交换页都会被分配一个比特。这是在内核已经为每个交换设备的每个交换
> +页分配的8位（在2.6.34之前是16位）上增加的。(Hugh Dickins观察到，frontswap可能
> +会偷取现有的8个比特，但是我们以后再来担心这个小的优化问题)。对于标准的4K页面大小的
> +非常大的交换盘（这很罕见），这是每32GB交换盘1MB开销。
> +
> +当交换页存储在transcendent memory中而不是写到磁盘上时，有一个副作用，即这可能会
> +产生更多的内存压力，有可能超过其他的优点。一个backend，比如zcache，必须实现策略
> +来仔细（但动态地）管理内存限制，以确保这种情况不会发生。
> +
> +* 好吧，那就用内核骇客能理解的术语来快速概述一下这个frontswap补丁的作用如何？
> +
> +我们假设在内核初始化过程中，一个frontswap 的 “backend” 已经注册了；这个注册表
> +明这个frontswap 的 “backend” 可以访问一些不被内核直接访问的“内存”。它到底提
> +供了多少内存是完全动态和随机的。
> +
> +每当一个交换设备被交换时，就会调用frontswap_init()，把交换设备的编号（又称“类
> +型”）作为一个参数传给它。这就通知了frontswap，以期待 “store” 与该号码相关的交
> +换页的尝试。
> +
> +每当交换子系统准备将一个页面写入交换设备时（参见swap_writepage()），就会调用
> +frontswap_store。Frontswap与frontswap backend协商，如果backend说它没有空
> +间，frontswap_store返回-1，内核就会照常把页换到交换设备上。注意，来自frontswap
> +backend的响应对内核来说是不可预测的；它可能选择从不接受一个页面，可能接受每九个
> +页面，也可能接受每一个页面。但是如果backend确实接受了一个页面，那么这个页面的数
> +据已经被复制并与类型和偏移量相关联了，而且backend保证了数据的持久性。在这种情况
> +下，frontswap在交换设备的“frontswap_map” 中设置了一个位，对应于交换设备上的
> +页面偏移量，否则它就会将数据写入该设备。
> +
> +当交换子系统需要交换一个页面时（swap_readpage()），它首先调用frontswap_load()，
> +检查frontswap_map，看这个页面是否早先被frontswap backend接受。如果是，该页
> +的数据就会从frontswap后端填充，换入就完成了。如果不是，正常的交换代码将被执行，
> +以便从真正的交换设备上获得这一页的数据。
> +
> +所以每次frontswap backend接受一个页面时，交换设备的读取和（可能）交换设备的写
> +入都被 “frontswap backend store” 和（可能）“frontswap backend loads”
> +所取代，这可能会快得多。
> +
> +* frontswap不能被配置为一个 “特殊的” 交换设备，它的优先级要高于任何真正的交换
> +  设备（例如像zswap，或者可能是swap-over-nbd/NFS）？
> +
> +首先，现有的交换子系统不允许有任何种类的交换层次结构。也许它可以被重写以适应层次
> +结构，但这将需要相当大的改变。即使它被重写，现有的交换子系统也使用了块I/O层，它
> +假定交换设备是固定大小的，其中的任何页面都是可线性寻址的。Frontswap几乎没有触
> +及现有的交换子系统，而是围绕着块I/O子系统的限制，提供了大量的灵活性和动态性。
> +
> +例如，frontswap backend对任何交换页的接受是完全不可预测的。这对frontswap backend
> +的定义至关重要，因为它赋予了backend完全动态的决定权。在zcache中，人们无法预
> +先知道一个页面的可压缩性如何。可压缩性 “差” 的页面会被拒绝，而 “差” 本身也可
> +以根据当前的内存限制动态地定义。
> +
> +此外，frontswap是完全同步的，而真正的交换设备，根据定义，是异步的，并且使用
> +块I/O。块I/O层不仅是不必要的，而且可能进行 “优化”，这对面向RAM的设备来说是
> +不合适的，包括将一些页面的写入延迟相当长的时间。同步是必须的，以确保后端的动
> +态性，并避免棘手的竞争条件，这将不必要地大大增加frontswap和/或块I/O子系统的
> +复杂性。也就是说，只有最初的 “store” 和 “load” 操作是需要同步的。一个独立
> +的异步线程可以自由地操作由frontswap存储的页面。例如，RAMster中的 “remotification”
> +线程使用标准的异步内核套接字，将压缩的frontswap页面移动到远程机器。同样，
> +KVM的客户方实现可以进行客户内压缩，并使用 “batched” hypercalls。
> +
> +在虚拟化环境中，动态性允许管理程序（或主机操作系统）做“intelligent overcommit”。
> +例如，它可以选择只接受页面，直到主机交换可能即将发生，然后强迫客户机做他们
> +自己的交换。
> +
> +transcendent memory规格的frontswap有一个坏处。因为任何 “store” 都可
> +能失败，所以必须在一个真正的交换设备上有一个真正的插槽来交换页面。因此，
> +frontswap必须作为每个交换设备的 “影子” 来实现，它有可能容纳交换设备可能
> +容纳的每一个页面，也有可能根本不容纳任何页面。这意味着frontswap不能包含比
> +swap设备总数更多的页面。例如，如果在某些安装上没有配置交换设备，frontswap
> +就没有用。无交换设备的便携式设备仍然可以使用frontswap，但是这种设备的
> +backend必须配置某种 “ghost” 交换设备，并确保它永远不会被使用。
> +
> +
> +* 为什么会有这种关于 “重复存储” 的奇怪定义？如果一个页面以前被成功地存储过，
> +  难道它不能总是被成功地覆盖吗？
> +
> +几乎总是可以的，不，有时不能。考虑一个例子，数据被压缩了，原来的4K页面被压
> +缩到了1K。现在，有人试图用不可压缩的数据覆盖该页，因此会占用整个4K。但是
> +backend没有更多的空间了。在这种情况下，这个存储必须被拒绝。每当frontswap
> +拒绝一个会覆盖的存储时，它也必须使旧的数据作废，并确保它不再被访问。因为交
> +换子系统会把新的数据写到读交换设备上，这是确保一致性的正确做法。
> +
> +* 为什么frontswap补丁会创建新的头文件swapfile.h？
> +
> +frontswap代码依赖于一些swap子系统内部的数据结构，这些数据结构多年来一直
> +在静态和全局之间来回移动。这似乎是一个合理的妥协：将它们定义为全局，但在一
> +个新的包含文件中声明它们，该文件不被包含swap.h的大量源文件所包含。
> +
> +Dan Magenheimer，最后更新于2012年4月9日
> diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
> index 2f9834eb9475..cc8d68b0cbb5 100644
> --- a/Documentation/translations/zh_CN/vm/index.rst
> +++ b/Documentation/translations/zh_CN/vm/index.rst
> @@ -26,11 +26,11 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
>     damon/index
>     free_page_reporting
>     highmem
> +   frontswap
>
>  TODOLIST:
>  * arch_pgtable_helpers
>  * free_page_reporting
> -* frontswap
>  * hmm
>  * hwpoison
>  * hugetlbfs_reserv
> --
> 2.27.0
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 03/12] docs/zh_CN: add vm memory-model translation
  2022-03-05 16:26 ` [PATCH 03/12] docs/zh_CN: add vm memory-model translation Yanteng Si
@ 2022-03-08 12:37   ` Alex Shi
  2022-03-14 11:18     ` yanteng si
  0 siblings, 1 reply; 21+ messages in thread
From: Alex Shi @ 2022-03-08 12:37 UTC (permalink / raw)
  To: Yanteng Si
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

On Sun, Mar 6, 2022 at 12:24 AM Yanteng Si <siyanteng01@gmail.com> wrote:
>
> Translate .../vm/memory-model.rst into Chinese.
>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  Documentation/translations/zh_CN/vm/index.rst |   3 +-
>  .../translations/zh_CN/vm/memory-model.rst    | 135 ++++++++++++++++++
>  2 files changed, 137 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/translations/zh_CN/vm/memory-model.rst
>
> diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
> index dd0b3d4c0ab8..186f85a156c0 100644
> --- a/Documentation/translations/zh_CN/vm/index.rst
> +++ b/Documentation/translations/zh_CN/vm/index.rst
> @@ -28,13 +28,14 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
>     highmem
>     frontswap
>     hwpoison
> +   memory-model
>
>  TODOLIST:
>  * arch_pgtable_helpers
>  * free_page_reporting
>  * hmm
>  * hugetlbfs_reserv
> -* memory-model
> +
>  * mmu_notifier
>  * numa
>  * overcommit-accounting
> diff --git a/Documentation/translations/zh_CN/vm/memory-model.rst b/Documentation/translations/zh_CN/vm/memory-model.rst
> new file mode 100644
> index 000000000000..5fe475581cbd
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/vm/memory-model.rst
> @@ -0,0 +1,135 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +:Original: Documentation/vm/memory-model.rst
> +
> +:翻译:
> +
> + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> +
> +:校译:
> +
> +
> +============
> +物理内存模型
> +============
> +
> +系统中的物理内存可以用不同的方式进行寻址。最简单的情况是，物理内存从地址0开
> +始，跨越一个连续的范围，直到最大的地址。然而，这个范围可能包含CPU无法访问的
> +小孔隙。那么，在完全不同的地址可能有几个连续的范围。而且，别忘了NUMA，即不
> +同的内存库连接到不同的CPU。
> +
> +Linux使用两种内存模型中的一种对这种多样性进行抽象。FLATMEM和SPARSEM。每
> +个架构都定义了它所支持的内存模型，默认的内存模型是什么，以及是否有可能手动
> +覆盖该默认值。
> +
> +所有的内存模型都使用排列在一个或多个数组中的 `struct page` 来跟踪物理页
> +帧的状态。
> +
> +无论选择哪种内存模型，物理页框号（PFN）和相应的 `struct page` 之间都存
> +在一对一的映射关系。
> +
> +每个内存模型都定义了 :c:func:`pfn_to_page` 和 :c:func:`page_to_pfn`
> +帮助函数，允许从PFN到 `struct page` 的转换，反之亦然。
> +
> +FLATMEM
> +=======
> +
> +最简单的内存模型是FLATMEM。这个模型适用于非NUMA系统的连续或大部分连续的
> +物理内存。
> +
> +在FLATMEM内存模型中，有一个全局的 `mem_map` 数组来映射整个物理内存。对
> +于大多数架构，孔隙在 `mem_map` 数组中都有条目。与孔洞相对应的 `struct page`
> +对象从未被完全初始化。
> +
> +为了分配 `mem_map` 数组，架构特定的设置代码应该调用free_area_init()函数。
> +然而，在调用memblock_free_all()函数之前，映射数组是不能使用的，该函数
> +将所有的内存交给页分配器。
> +
> +一个架构可能会释放 `mem_map` 数组中不包括实际物理页的部分。在这种情况下，特
> +定架构的 :c:func:`pfn_valid` 实现应该考虑到 `mem_map` 中的孔隙。
> +
> +使用FLATMEM，PFN和 `struct page` 之间的转换是直接的。 `PFN - ARCH_PFN_OFFSET`
> +是 `mem_map` 数组的一个索引。
> +
> +`ARCH_PFN_OFFSET` 定义了物理内存起始地址不同于0的系统的第一个页框号。
> +
> +SPARSEMEM
> +=========
> +
> +SPARSEMEM是Linux中最通用的内存模型，它是唯一支持若干高级功能的内存模型，
> +如物理内存的热插拔、非易失性内存设备的替代内存图和较大系统的内存图的延迟
> +初始化。
> +
> +SPARSEMEM模型将物理内存显示为一个部分的集合。一个区段用mem_section结构
> +体表示，它包含 `section_mem_map` ，从逻辑上讲，它是一个指向 `struct page`
> +阵列的指针。然而，它被存储在一些其他的magic中，以帮助分区管理。区段的大小
> +和最大区段数是使用 `SECTION_SIZE_BITS` 和 `MAX_PHYSMEM_BITS` 常量
> +来指定的，这两个常量是由每个支持SPARSEMEM的架构定义的。 `MAX_PHYSMEM_BITS`
> +是一个架构所支持的物理地址的实际宽度，而 `SECTION_SIZE_BITS` 是一个任
> +意的值。
> +
> +最大的段数表示为 `NR_MEM_SECTIONS` ，定义为
> +
> +.. math::
> +
> +   NR\_MEM\_SECTIONS = 2 ^ {(MAX\_PHYSMEM\_BITS - SECTION\_SIZE\_BITS)}
> +
> +`mem_section` 对象被安排在一个叫做 `mem_sections` 的二维数组中。这个数组的
> +大小和位置取决于 `CONFIG_SPARSEM_EXTREME` 和可能的最大段数:
> +
> +* 当 `CONFIG_SPARSEMEM_EXTREME` 被禁用时， `mem_sections` 数组是静态的，有
> +  `NR_MEM_SECTIONS` 行。每一行持有一个 `mem_section` 对象。
> +* 当 `CONFIG_SPARSEMEM_EXTREME` 被启用时， `mem_sections` 数组被动态分配。
> +  每一行包含价值 `PAGE_SIZE` 的 `mem_section` 对象，行数的计算是为了适应所有的
> +  内存区。
> +
> +架构设置代码应该调用sparse_init()来初始化内存区和内存映射。
> +
> +通过SPARSEMEM，有两种可能的方式将PFN转换为相应的 `struct page` --"classic sparse"和
> + "sparse vmemmap"。选择是在构建时进行的，它由 `CONFIG_SPARSEMEM_VMEMMAP` 的
> + 值决定。
> +
> +Classic sparse在page->flags中编码了一个页面的段号，并使用PFN的高位来访问映射该页
> +框的段。在一个区段内，PFN是指向页数组的索引。
> +
> +Sparse vmemmapvmemmap使用虚拟映射的内存映射来优化pfn_to_page和page_to_pfn操
> +作。有一个全局的 `struct page *vmemmap` 指针，指向一个虚拟连续的 `struct page`
> +对象阵列。PFN是该数组的一个索引，`struct page` 从 `vmemmap` 的偏移量是该页的PFN。
> +
> +为了使用vmemmap，一个架构必须保留一个虚拟地址的范围，以映射包含内存映射的物理页，并
> +确保 `vmemmap`指向该范围。此外，架构应该实现 :c:func:`vmemmap_populate` 方法，
> +它将分配物理内存并为虚拟内存映射创建页表。如果一个架构对vmemmap映射没有任何特殊要求，
> +它可以使用通用内存管理提供的默认 :c:func:`vmemmap_populate_basepages`。
> +
> +虚拟映射的内存映射允许将持久性内存设备的 `struct page` 对象存储在这些设备上预先分
> +配的存储中。这种存储用vmem_altmap结构表示，最终通过一长串的函数调用传递给
> +vmemmap_populate()。vmemmap_populate()实现可以使用 `vmem_altmap` 和
> +:c:func:`vmemmap_alloc_block_buf` 助手来分配持久性内存设备上的内存映射。
> +
> +ZONE_DEVICE
> +===========
> +`ZONE_DEVICE` 设施建立在 `SPARSEM_VMEMMAP` 之上，为设备驱动识别的物理地址范
> +围提供 `struct page` `mem_map` 服务。 `ZONE_DEVICE` 的 "设备" 方面与以下
> +事实有关：这些地址范围的页面对象从未被在线标记过，而且必须对设备进行引用，而不仅仅
> +是页面，以保持内存被pinned以便使用。 `ZONE_DEVICE` ，通过 :c:func:`devm_memremap_pages` ，

以保持内存被“锁定”以便使用？

for others:
Reviewed-by: Alex Shi <alexs@kernel.org>

Thanks

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 02/12] docs/zh_CN: add vm hwpoison translation
  2022-03-05 16:26 ` [PATCH 02/12] docs/zh_CN: add vm hwpoison translation Yanteng Si
@ 2022-03-08 13:04   ` Alex Shi
  2022-03-14 11:56     ` yanteng si
  0 siblings, 1 reply; 21+ messages in thread
From: Alex Shi @ 2022-03-08 13:04 UTC (permalink / raw)
  To: Yanteng Si
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

On Sun, Mar 6, 2022 at 12:24 AM Yanteng Si <siyanteng01@gmail.com> wrote:
>
> Translate .../vm/hwpoison.rst into Chinese.
>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  .../translations/zh_CN/vm/hwpoison.rst        | 166 ++++++++++++++++++
>  Documentation/translations/zh_CN/vm/index.rst |   2 +-
>  2 files changed, 167 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/translations/zh_CN/vm/hwpoison.rst
>
> diff --git a/Documentation/translations/zh_CN/vm/hwpoison.rst b/Documentation/translations/zh_CN/vm/hwpoison.rst
> new file mode 100644
> index 000000000000..7c4477c33e56
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/vm/hwpoison.rst
> @@ -0,0 +1,166 @@
> +
> +:Original: Documentation/vm/hwpoison.rst
> +
> +:翻译:
> +
> + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> +
> +:校译:
> +
> +
> +========
> +hwpoison
> +========
> +
> +什么是hwpoison?
> +===============
> +
> +
> +即将推出的英特尔CPU支持从一些内存错误中恢复（ ``MCA恢复`` ）。这需要操作系统宣布
> +一个页面"poisoned"，杀死与之相关的进程，并避免在未来使用它。
> +
> +这个补丁包在虚拟机中实现了必要的基础设施。

"实现了必要的(编程)框架"?

> +
> +引用概述中的评论::
> +
> +       高水平的机器检查处理程序。处理被硬件报告为损坏的页面，通常是由于2位ECC内存或

“高层次的机器检查处理程序”？

> +       高速缓存故障。
> +
> +       这主要是针对在后台检测到的损坏的页面。当当前的CPU试图访问它时，当前运行的进程
> +       可以直接被杀死。这意味着，如果错误由于某种原因不能被处理，就可以安全地忽略它，
> +       因为还没有访问损坏的页面。相反，当这种情况发生时，另一个机器检查将出现。

change the words to: 因为还没有访问损坏的页面, 如果错误由于某种原因不能被处理，就可以安全地忽略它. 而不是用另外一个机器检查去处理它。

> +
> +       处理不同状态的页面缓存页。这里棘手的部分是，我们可以异步访问任何页面给其他虚拟

相对于其他虚拟机用户， 我们可以异步访问任何页面。

> +       机用户，因为内存故障可能随时随地发生，可能违反了他们的一些假设。这就是为什么这
> +       段代码必须非常小心。一般来说，它试图使用正常的锁定规则，如获得标准锁，即使这意
> +       味着错误处理可能需要很长的时间。
> +
> +       这里的一些操作有点低效，并且具有非线性的算法复杂性，因为数据结构没有针对这种情
> +       况进行优化。特别是从vma到进程的映射就是这种情况。由于这种情况预计是罕见的，我
> +       们希望我们可以摆脱这种情况。
> +
> +该代码由mm/memory-failure.c中的高级处理程序、一个新的页面poison 位和虚拟机中的
> +各种检查组成，用来处理poison 的页面。
> +
> +现在的主要针对的是KVM客户机，但它适用于所有类型的应用程序。支持KVM需要最近的qemu-kvm

现在主要目标是KVM客户机？

> +版本。
> +
> +对于KVM的使用，需要一个新的信号类型，这样KVM就可以用适当的地址将机器检查注入到客户
> +机中。这在理论上也允许其他应用程序处理内存故障。我们的期望是，几乎所有的应用程序都不
> +会这样做，但一些非常专业的应用程序可能会这样做。

change to: “所有的应用程序都不要这样做”？

> +
> +故障恢复模式
> +============
> +
> +有两种（实际上是三种）模式的内存故障恢复可以在。
> +
> +vm.memory_failure_recovery sysctl 置零:
> +       所有的内存故障都会导致panic。请不要尝试恢复。
> +
> +early kill

早期处理？

> +       (可以在全局和每个进程中控制) 一旦检测到错误，立即向应用程序发送SIGBUS 这允许
> +       应用程序以温和的方式处理内存错误（例如，放弃受影响的对象） 这是KVM qemu使用的
> +       模式。
> +
> +late kill

推迟处理？

> +       当应用程序运行到损坏的页面时，发送SIGBUS。这对不知道内存错误的应用程序来说是
> +       最好的，默认情况下注意一些页面总是被当作 late kill处理。
> +
> +用户控制
> +========
> +
> +vm.memory_failure_recovery
> +       参阅 sysctl.txt
> +
> +vm.memory_failure_early_kill
> +       全局启用early kill
> +
> +PR_MCE_KILL
> +       设置early/late kill mode/revert 到系统默认值。
> +
> +       arg1: PR_MCE_KILL_CLEAR:
> +               恢复到系统默认值
> +       arg1: PR_MCE_KILL_SET:
> +               arg2定义了线程特定模式
> +
> +               PR_MCE_KILL_EARLY:
> +                       Early kill
> +               PR_MCE_KILL_LATE:
> +                       Late kill
> +               PR_MCE_KILL_DEFAULT
> +                       使用系统全局默认值
> +
> +       注意，如果你想有一个专门的线程代表进程处理SIGBUS(BUS_MCEERR_AO)，你应该在
> +       指定线程上调用prctl(PR_MCE_KILL_EARLY)。否则，SIGBUS将被发送到主线程。
> +
> +PR_MCE_KILL_GET
> +       返回当前模式
> +
> +测试
> +====
> +
> +* madvise(MADV_HWPOISON, ....) (as root) - 在测试过程中Poison一个页面
> +
> +* 通过debugfs ``/sys/kernel/debug/hwpoison/`` hwpoison-inject模块
> +
> +  corrupt-pfn
> +       在PFN处注入hwpoison故障，并echoed到这个文件。这做了一些早期过滤，以避
> +       免在测试套件中损坏的非预期页面。

以避免在测试套件中损坏非预期页面？

This doc is hard to understand for details, guess that cause more
trouble to transalate.

Thanks
Alex

> +  unpoison-pfn
> +       在PFN的Software-unpoison 页面呼应到这个文件。这样，一个页面可以再次被
> +       复用。这只对Linux注入的故障起作用，对真正的内存故障不起作用。
> +
> +  注意这些注入接口并不稳定，可能会在不同的内核版本中发生变化
> +
> +  corrupt-filter-dev-major, corrupt-filter-dev-minor
> +       只处理与块设备major/minor定义的文件系统相关的页面的内存故障。-1U是通
> +       配符值。这应该只用于人工注入的测试。
> +
> +  corrupt-filter-memcg
> +       限制注入到memgroup拥有的页面。由memcg的inode号指定。
> +
> +       Example::
> +
> +               mkdir /sys/fs/cgroup/mem/hwpoison
> +
> +               usemem -m 100 -s 1000 &
> +               echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks
> +
> +               memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ')
> +               echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg
> +
> +               page-types -p `pidof init`   --hwpoison  # shall do nothing
> +               page-types -p `pidof usemem` --hwpoison  # poison its pages
> +
> +  corrupt-filter-flags-mask, corrupt-filter-flags-value
> +       当指定时，只有在((page_flags & mask) == value)的情况下才会poison页面。
> +       这允许对许多种类的页面进行压力测试。page_flags与/proc/kpageflags中的相
> +       同。这些标志位在include/linux/kernel-page-flags.h中定义，并在
> +       Documentation/admin-guide/mm/pagemap.rst中记录。
> +
> +* 架构特定的MCE注入器
> +
> +  x86 有 mce-inject, mce-test
> +
> +  在mce-test中的一些便携式hwpoison测试程序，见下文。
> +
> +引用
> +====
> +
> +http://halobates.de/mce-lc09-2.pdf
> +       09年LinuxCon的概述演讲
> +
> +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git
> +       测试套件（在tsrc中的hwpoison特定可移植测试）。
> +
> +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-inject.git
> +       x86特定的注入器
> +
> +
> +限制
> +====
> +- 不是所有的页面类型都被支持，而且永远不会。大多数内核内部对象不能被恢
> +  复，目前只有LRU页。
> +
> +---
> +Andi Kleen, 2009年10月
> diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
> index cc8d68b0cbb5..dd0b3d4c0ab8 100644
> --- a/Documentation/translations/zh_CN/vm/index.rst
> +++ b/Documentation/translations/zh_CN/vm/index.rst
> @@ -27,12 +27,12 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
>     free_page_reporting
>     highmem
>     frontswap
> +   hwpoison
>
>  TODOLIST:
>  * arch_pgtable_helpers
>  * free_page_reporting
>  * hmm
> -* hwpoison
>  * hugetlbfs_reserv
>  * memory-model
>  * mmu_notifier
> --
> 2.27.0
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 04/12] docs/zh_CN: add vm mmu_notifier translation
  2022-03-05 16:26 ` [PATCH 04/12] docs/zh_CN: add vm mmu_notifier translation Yanteng Si
@ 2022-03-08 15:02   ` Alex Shi
  0 siblings, 0 replies; 21+ messages in thread
From: Alex Shi @ 2022-03-08 15:02 UTC (permalink / raw)
  To: Yanteng Si
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

On Sun, Mar 6, 2022 at 12:24 AM Yanteng Si <siyanteng01@gmail.com> wrote:
>
> Translate .../vm/mmu_notifier.rst into Chinese.
>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>

Reviewed-by: Alex Shi <alexs@kernel.org>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 05/12] docs/zh_CN: add vm overcommit-accounting translation
  2022-03-05 16:26 ` [PATCH 05/12] docs/zh_CN: add vm overcommit-accounting translation Yanteng Si
@ 2022-03-08 15:16   ` Alex Shi
  2022-03-14 12:03     ` yanteng si
  0 siblings, 1 reply; 21+ messages in thread
From: Alex Shi @ 2022-03-08 15:16 UTC (permalink / raw)
  To: Yanteng Si
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

On Sun, Mar 6, 2022 at 12:25 AM Yanteng Si <siyanteng01@gmail.com> wrote:
>
> Translate .../vm/overcommit-accounting.rst into Chinese.
>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
>  Documentation/translations/zh_CN/vm/index.rst |  2 +-
>  .../zh_CN/vm/overcommit-accounting.rst        | 86 +++++++++++++++++++
>  2 files changed, 87 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/translations/zh_CN/vm/overcommit-accounting.rst
>
> diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
> index 919e879b8167..2a3a93a4c050 100644
> --- a/Documentation/translations/zh_CN/vm/index.rst
> +++ b/Documentation/translations/zh_CN/vm/index.rst
> @@ -30,6 +30,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
>     hwpoison
>     memory-model
>     mmu_notifier
> +   overcommit-accounting
>
>  TODOLIST:
>  * arch_pgtable_helpers
> @@ -37,7 +38,6 @@ TODOLIST:
>  * hmm
>  * hugetlbfs_reserv
>  * numa
> -* overcommit-accounting
>  * page_migration
>  * page_frags
>  * page_owner
> diff --git a/Documentation/translations/zh_CN/vm/overcommit-accounting.rst b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst
> new file mode 100644
> index 000000000000..1e3eae1338cb
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst
> @@ -0,0 +1,86 @@
> +:Original: Documentation/vm/overcommit.rst

Documentation/vm/overcommit-accounting.rst ?

> +
> +:翻译:
> +
> + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> +
> +:校译:
> +
> +
> +
> +==============
> +Overcommit审计

overcommit -> 超量使用?

> +==============
> +
> +Linux内核支持下列overcommit处理模式
> +
> +0
> +       启发式overcommit处理。拒绝明显的地址空间overcommit。用于一个典型的系统。
> +       它确保严重的疯狂分配失败，同时允许overcommit以减少swap的使用。在这种模式下，
> +       允许root分配稍多的内存。这是默认的。
> +1
> +       总是overcommit。适用于一些科学应用。经典的例子是使用稀疏数组的代码，只是依赖
> +       几乎完全由零页组成的虚拟内存
> +
> +2
> +       不overcommit。系统提交的总地址空间不允许超过swap+一个可配置的物理RAM的数量
> +       （默认为50%）。根据你使用的数量，在大多数情况下，这意味着一个进程在访问页面时
> +       不会被杀死，但会在内存分配上收到相应的错误。
> +
> +       对于那些想保证他们的内存分配在未来可用而又不需要初始化每一个页面的应用程序来说
> +       是很有用的。
> +
> +overcommit策略是通过sysctl  `vm.overcommit_memory` 设置的。
> +
> +可以通过 `vm.overcommit_ratio` （百分比）或 `vm.overcommit_kbytes` （绝对值）
> +来设置超限数量。这些只有在 `vm.overcommit_memory` 被设置为2时才有效果。
> +
> +在 ``/proc/meminfo`` 中可以分别以CommitLimit和Committed_AS的形式查看当前
> +的overcommit和提交量。
> +
> +陷阱
> +====
> +
> +C语言的堆栈增长是一个隐含的mremap。如果你想得到绝对的保证，并在接近边缘的地方运行，
> +你 **必须** 为你认为你需要的最大尺寸的堆栈进行mmap。对于典型的堆栈使用来说，这并
> +不重要，但如果你真的非常关心的话，这就是一个值得关注的案例。
> +
> +
> +在模式2中，MAP_NORESERVE标志被忽略。
> +
> +
> +它是如何工作的
> +==============
> +
> +overcommit是基于以下规则
> +
> +For a file backed map

对于文件映射

> +       | SHARED or READ-only   -       0 cost (该文件是映射而不是交换)
> +       | PRIVATE WRITABLE      -       每个实例的映射大小
> +
> +For an anonymous or ``/dev/zero`` map
对于匿名或者/dev/zero 映射？

> +       | SHARED                        -       映射的大小
> +       | PRIVATE READ-only     -       0 cost (但作用不大)
> +       | PRIVATE WRITABLE      -       每个实例的映射大小
> +
> +Additional accounting
额外的计数

> +       | 通过mmap制作可写副本的页面
> +       | 从同一池中提取的shmfs内存
> +
> +状态
> +====
> +
> +*      我们核算mmap内存映射
> +*      我们核算mprotect在提交中的变化
> +*      我们核算mremap的大小变化
> +*      我们的审计 brk
> +*      审计munmap
> +*      我们在/proc中报告commit 状态
> +*      核对并检查分叉的情况
> +*      审查堆栈处理/执行中的构建
> +*      叙述SHMfs的情况
> +*      实现实际限制的执行
> +
> +待续
> +====
> +*      帐户trace页（这很难）。

ptrace 页计数？

Thanks
Alex

> --
> 2.27.0
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 03/12] docs/zh_CN: add vm memory-model translation
  2022-03-08 12:37   ` Alex Shi
@ 2022-03-14 11:18     ` yanteng si
  0 siblings, 0 replies; 21+ messages in thread
From: yanteng si @ 2022-03-14 11:18 UTC (permalink / raw)
  To: Alex Shi
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

Alex Shi <seakeel@gmail.com> 于2022年3月8日周二 20:38写道：
>
> On Sun, Mar 6, 2022 at 12:24 AM Yanteng Si <siyanteng01@gmail.com> wrote:
> >
> > Translate .../vm/memory-model.rst into Chinese.
> >
> > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > ---
> >  Documentation/translations/zh_CN/vm/index.rst |   3 +-
> >  .../translations/zh_CN/vm/memory-model.rst    | 135 ++++++++++++++++++
> >  2 files changed, 137 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/translations/zh_CN/vm/memory-model.rst
> >
> > diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
> > index dd0b3d4c0ab8..186f85a156c0 100644
> > --- a/Documentation/translations/zh_CN/vm/index.rst
> > +++ b/Documentation/translations/zh_CN/vm/index.rst
> > @@ -28,13 +28,14 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
> >     highmem
> >     frontswap
> >     hwpoison
> > +   memory-model
> >
> >  TODOLIST:
> >  * arch_pgtable_helpers
> >  * free_page_reporting
> >  * hmm
> >  * hugetlbfs_reserv
> > -* memory-model
> > +
> >  * mmu_notifier
> >  * numa
> >  * overcommit-accounting
> > diff --git a/Documentation/translations/zh_CN/vm/memory-model.rst b/Documentation/translations/zh_CN/vm/memory-model.rst
> > new file mode 100644
> > index 000000000000..5fe475581cbd
> > --- /dev/null
> > +++ b/Documentation/translations/zh_CN/vm/memory-model.rst
> > @@ -0,0 +1,135 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +:Original: Documentation/vm/memory-model.rst
> > +
> > +:翻译:
> > +
> > + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> > +
> > +:校译:
> > +
> > +
> > +============
> > +物理内存模型
> > +============
> > +
> > +系统中的物理内存可以用不同的方式进行寻址。最简单的情况是，物理内存从地址0开
> > +始，跨越一个连续的范围，直到最大的地址。然而，这个范围可能包含CPU无法访问的
> > +小孔隙。那么，在完全不同的地址可能有几个连续的范围。而且，别忘了NUMA，即不
> > +同的内存库连接到不同的CPU。
> > +
> > +Linux使用两种内存模型中的一种对这种多样性进行抽象。FLATMEM和SPARSEM。每
> > +个架构都定义了它所支持的内存模型，默认的内存模型是什么，以及是否有可能手动
> > +覆盖该默认值。
> > +
> > +所有的内存模型都使用排列在一个或多个数组中的 `struct page` 来跟踪物理页
> > +帧的状态。
> > +
> > +无论选择哪种内存模型，物理页框号（PFN）和相应的 `struct page` 之间都存
> > +在一对一的映射关系。
> > +
> > +每个内存模型都定义了 :c:func:`pfn_to_page` 和 :c:func:`page_to_pfn`
> > +帮助函数，允许从PFN到 `struct page` 的转换，反之亦然。
> > +
> > +FLATMEM
> > +=======
> > +
> > +最简单的内存模型是FLATMEM。这个模型适用于非NUMA系统的连续或大部分连续的
> > +物理内存。
> > +
> > +在FLATMEM内存模型中，有一个全局的 `mem_map` 数组来映射整个物理内存。对
> > +于大多数架构，孔隙在 `mem_map` 数组中都有条目。与孔洞相对应的 `struct page`
> > +对象从未被完全初始化。
> > +
> > +为了分配 `mem_map` 数组，架构特定的设置代码应该调用free_area_init()函数。
> > +然而，在调用memblock_free_all()函数之前，映射数组是不能使用的，该函数
> > +将所有的内存交给页分配器。
> > +
> > +一个架构可能会释放 `mem_map` 数组中不包括实际物理页的部分。在这种情况下，特
> > +定架构的 :c:func:`pfn_valid` 实现应该考虑到 `mem_map` 中的孔隙。
> > +
> > +使用FLATMEM，PFN和 `struct page` 之间的转换是直接的。 `PFN - ARCH_PFN_OFFSET`
> > +是 `mem_map` 数组的一个索引。
> > +
> > +`ARCH_PFN_OFFSET` 定义了物理内存起始地址不同于0的系统的第一个页框号。
> > +
> > +SPARSEMEM
> > +=========
> > +
> > +SPARSEMEM是Linux中最通用的内存模型，它是唯一支持若干高级功能的内存模型，
> > +如物理内存的热插拔、非易失性内存设备的替代内存图和较大系统的内存图的延迟
> > +初始化。
> > +
> > +SPARSEMEM模型将物理内存显示为一个部分的集合。一个区段用mem_section结构
> > +体表示，它包含 `section_mem_map` ，从逻辑上讲，它是一个指向 `struct page`
> > +阵列的指针。然而，它被存储在一些其他的magic中，以帮助分区管理。区段的大小
> > +和最大区段数是使用 `SECTION_SIZE_BITS` 和 `MAX_PHYSMEM_BITS` 常量
> > +来指定的，这两个常量是由每个支持SPARSEMEM的架构定义的。 `MAX_PHYSMEM_BITS`
> > +是一个架构所支持的物理地址的实际宽度，而 `SECTION_SIZE_BITS` 是一个任
> > +意的值。
> > +
> > +最大的段数表示为 `NR_MEM_SECTIONS` ，定义为
> > +
> > +.. math::
> > +
> > +   NR\_MEM\_SECTIONS = 2 ^ {(MAX\_PHYSMEM\_BITS - SECTION\_SIZE\_BITS)}
> > +
> > +`mem_section` 对象被安排在一个叫做 `mem_sections` 的二维数组中。这个数组的
> > +大小和位置取决于 `CONFIG_SPARSEM_EXTREME` 和可能的最大段数:
> > +
> > +* 当 `CONFIG_SPARSEMEM_EXTREME` 被禁用时， `mem_sections` 数组是静态的，有
> > +  `NR_MEM_SECTIONS` 行。每一行持有一个 `mem_section` 对象。
> > +* 当 `CONFIG_SPARSEMEM_EXTREME` 被启用时， `mem_sections` 数组被动态分配。
> > +  每一行包含价值 `PAGE_SIZE` 的 `mem_section` 对象，行数的计算是为了适应所有的
> > +  内存区。
> > +
> > +架构设置代码应该调用sparse_init()来初始化内存区和内存映射。
> > +
> > +通过SPARSEMEM，有两种可能的方式将PFN转换为相应的 `struct page` --"classic sparse"和
> > + "sparse vmemmap"。选择是在构建时进行的，它由 `CONFIG_SPARSEMEM_VMEMMAP` 的
> > + 值决定。
> > +
> > +Classic sparse在page->flags中编码了一个页面的段号，并使用PFN的高位来访问映射该页
> > +框的段。在一个区段内，PFN是指向页数组的索引。
> > +
> > +Sparse vmemmapvmemmap使用虚拟映射的内存映射来优化pfn_to_page和page_to_pfn操
> > +作。有一个全局的 `struct page *vmemmap` 指针，指向一个虚拟连续的 `struct page`
> > +对象阵列。PFN是该数组的一个索引，`struct page` 从 `vmemmap` 的偏移量是该页的PFN。
> > +
> > +为了使用vmemmap，一个架构必须保留一个虚拟地址的范围，以映射包含内存映射的物理页，并
> > +确保 `vmemmap`指向该范围。此外，架构应该实现 :c:func:`vmemmap_populate` 方法，
> > +它将分配物理内存并为虚拟内存映射创建页表。如果一个架构对vmemmap映射没有任何特殊要求，
> > +它可以使用通用内存管理提供的默认 :c:func:`vmemmap_populate_basepages`。
> > +
> > +虚拟映射的内存映射允许将持久性内存设备的 `struct page` 对象存储在这些设备上预先分
> > +配的存储中。这种存储用vmem_altmap结构表示，最终通过一长串的函数调用传递给
> > +vmemmap_populate()。vmemmap_populate()实现可以使用 `vmem_altmap` 和
> > +:c:func:`vmemmap_alloc_block_buf` 助手来分配持久性内存设备上的内存映射。
> > +
> > +ZONE_DEVICE
> > +===========
> > +`ZONE_DEVICE` 设施建立在 `SPARSEM_VMEMMAP` 之上，为设备驱动识别的物理地址范
> > +围提供 `struct page` `mem_map` 服务。 `ZONE_DEVICE` 的 "设备" 方面与以下
> > +事实有关：这些地址范围的页面对象从未被在线标记过，而且必须对设备进行引用，而不仅仅
> > +是页面，以保持内存被pinned以便使用。 `ZONE_DEVICE` ，通过 :c:func:`devm_memremap_pages` ，
>
> 以保持内存被“锁定”以便使用？
Ok,thanks!

Thanks,
Yanteng
>
> for others:
> Reviewed-by: Alex Shi <alexs@kernel.org>
>
> Thanks

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 02/12] docs/zh_CN: add vm hwpoison translation
  2022-03-08 13:04   ` Alex Shi
@ 2022-03-14 11:56     ` yanteng si
  0 siblings, 0 replies; 21+ messages in thread
From: yanteng si @ 2022-03-14 11:56 UTC (permalink / raw)
  To: Alex Shi
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

Alex Shi <seakeel@gmail.com> 于2022年3月8日周二 21:04写道：
>
> On Sun, Mar 6, 2022 at 12:24 AM Yanteng Si <siyanteng01@gmail.com> wrote:
> >
> > Translate .../vm/hwpoison.rst into Chinese.
> >
> > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > ---
> >  .../translations/zh_CN/vm/hwpoison.rst        | 166 ++++++++++++++++++
> >  Documentation/translations/zh_CN/vm/index.rst |   2 +-
> >  2 files changed, 167 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/translations/zh_CN/vm/hwpoison.rst
> >
> > diff --git a/Documentation/translations/zh_CN/vm/hwpoison.rst b/Documentation/translations/zh_CN/vm/hwpoison.rst
> > new file mode 100644
> > index 000000000000..7c4477c33e56
> > --- /dev/null
> > +++ b/Documentation/translations/zh_CN/vm/hwpoison.rst
> > @@ -0,0 +1,166 @@
> > +
> > +:Original: Documentation/vm/hwpoison.rst
> > +
> > +:翻译:
> > +
> > + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> > +
> > +:校译:
> > +
> > +
> > +========
> > +hwpoison
> > +========
> > +
> > +什么是hwpoison?
> > +===============
> > +
> > +
> > +即将推出的英特尔CPU支持从一些内存错误中恢复（ ``MCA恢复`` ）。这需要操作系统宣布
> > +一个页面"poisoned"，杀死与之相关的进程，并避免在未来使用它。
> > +
> > +这个补丁包在虚拟机中实现了必要的基础设施。
>
> "实现了必要的(编程)框架"?
OK!
>
> > +
> > +引用概述中的评论::
> > +
> > +       高水平的机器检查处理程序。处理被硬件报告为损坏的页面，通常是由于2位ECC内存或
>
> “高层次的机器检查处理程序”？
>
> > +       高速缓存故障。
> > +
> > +       这主要是针对在后台检测到的损坏的页面。当当前的CPU试图访问它时，当前运行的进程
> > +       可以直接被杀死。这意味着，如果错误由于某种原因不能被处理，就可以安全地忽略它，
> > +       因为还没有访问损坏的页面。相反，当这种情况发生时，另一个机器检查将出现。
>
> change the words to: 因为还没有访问损坏的页面, 如果错误由于某种原因不能被处理，就可以安全地忽略它. 而不是用另外一个机器检查去处理它。
ok!
>
> > +
> > +       处理不同状态的页面缓存页。这里棘手的部分是，我们可以异步访问任何页面给其他虚拟
>
> 相对于其他虚拟机用户， 我们可以异步访问任何页面。
ok!
>
> > +       机用户，因为内存故障可能随时随地发生，可能违反了他们的一些假设。这就是为什么这
> > +       段代码必须非常小心。一般来说，它试图使用正常的锁定规则，如获得标准锁，即使这意
> > +       味着错误处理可能需要很长的时间。
> > +
> > +       这里的一些操作有点低效，并且具有非线性的算法复杂性，因为数据结构没有针对这种情
> > +       况进行优化。特别是从vma到进程的映射就是这种情况。由于这种情况预计是罕见的，我
> > +       们希望我们可以摆脱这种情况。
> > +
> > +该代码由mm/memory-failure.c中的高级处理程序、一个新的页面poison 位和虚拟机中的
> > +各种检查组成，用来处理poison 的页面。
> > +
> > +现在的主要针对的是KVM客户机，但它适用于所有类型的应用程序。支持KVM需要最近的qemu-kvm
>
> 现在主要目标是KVM客户机？
OK!
>
> > +版本。
> > +
> > +对于KVM的使用，需要一个新的信号类型，这样KVM就可以用适当的地址将机器检查注入到客户
> > +机中。这在理论上也允许其他应用程序处理内存故障。我们的期望是，几乎所有的应用程序都不
> > +会这样做，但一些非常专业的应用程序可能会这样做。
>
> change to: “所有的应用程序都不要这样做”？
ok!
>
> > +
> > +故障恢复模式
> > +============
> > +
> > +有两种（实际上是三种）模式的内存故障恢复可以在。
> > +
> > +vm.memory_failure_recovery sysctl 置零:
> > +       所有的内存故障都会导致panic。请不要尝试恢复。
> > +
> > +early kill
>
> 早期处理？
ok
>
> > +       (可以在全局和每个进程中控制) 一旦检测到错误，立即向应用程序发送SIGBUS 这允许
> > +       应用程序以温和的方式处理内存错误（例如，放弃受影响的对象） 这是KVM qemu使用的
> > +       模式。
> > +
> > +late kill
>
> 推迟处理？
ok
>
> > +       当应用程序运行到损坏的页面时，发送SIGBUS。这对不知道内存错误的应用程序来说是
> > +       最好的，默认情况下注意一些页面总是被当作 late kill处理。
> > +
> > +用户控制
> > +========
> > +
> > +vm.memory_failure_recovery
> > +       参阅 sysctl.txt
> > +
> > +vm.memory_failure_early_kill
> > +       全局启用early kill
> > +
> > +PR_MCE_KILL
> > +       设置early/late kill mode/revert 到系统默认值。
> > +
> > +       arg1: PR_MCE_KILL_CLEAR:
> > +               恢复到系统默认值
> > +       arg1: PR_MCE_KILL_SET:
> > +               arg2定义了线程特定模式
> > +
> > +               PR_MCE_KILL_EARLY:
> > +                       Early kill
> > +               PR_MCE_KILL_LATE:
> > +                       Late kill
> > +               PR_MCE_KILL_DEFAULT
> > +                       使用系统全局默认值
> > +
> > +       注意，如果你想有一个专门的线程代表进程处理SIGBUS(BUS_MCEERR_AO)，你应该在
> > +       指定线程上调用prctl(PR_MCE_KILL_EARLY)。否则，SIGBUS将被发送到主线程。
> > +
> > +PR_MCE_KILL_GET
> > +       返回当前模式
> > +
> > +测试
> > +====
> > +
> > +* madvise(MADV_HWPOISON, ....) (as root) - 在测试过程中Poison一个页面
> > +
> > +* 通过debugfs ``/sys/kernel/debug/hwpoison/`` hwpoison-inject模块
> > +
> > +  corrupt-pfn
> > +       在PFN处注入hwpoison故障，并echoed到这个文件。这做了一些早期过滤，以避
> > +       免在测试套件中损坏的非预期页面。
>
> 以避免在测试套件中损坏非预期页面？
>
> This doc is hard to understand for details, guess that cause more
> trouble to transalate.
Yes, but I will do my best to translate it and study it.

Thanks，
Yanteng
>
> Thanks
> Alex
>
> > +  unpoison-pfn
> > +       在PFN的Software-unpoison 页面呼应到这个文件。这样，一个页面可以再次被
> > +       复用。这只对Linux注入的故障起作用，对真正的内存故障不起作用。
> > +
> > +  注意这些注入接口并不稳定，可能会在不同的内核版本中发生变化
> > +
> > +  corrupt-filter-dev-major, corrupt-filter-dev-minor
> > +       只处理与块设备major/minor定义的文件系统相关的页面的内存故障。-1U是通
> > +       配符值。这应该只用于人工注入的测试。
> > +
> > +  corrupt-filter-memcg
> > +       限制注入到memgroup拥有的页面。由memcg的inode号指定。
> > +
> > +       Example::
> > +
> > +               mkdir /sys/fs/cgroup/mem/hwpoison
> > +
> > +               usemem -m 100 -s 1000 &
> > +               echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks
> > +
> > +               memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ')
> > +               echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg
> > +
> > +               page-types -p `pidof init`   --hwpoison  # shall do nothing
> > +               page-types -p `pidof usemem` --hwpoison  # poison its pages
> > +
> > +  corrupt-filter-flags-mask, corrupt-filter-flags-value
> > +       当指定时，只有在((page_flags & mask) == value)的情况下才会poison页面。
> > +       这允许对许多种类的页面进行压力测试。page_flags与/proc/kpageflags中的相
> > +       同。这些标志位在include/linux/kernel-page-flags.h中定义，并在
> > +       Documentation/admin-guide/mm/pagemap.rst中记录。
> > +
> > +* 架构特定的MCE注入器
> > +
> > +  x86 有 mce-inject, mce-test
> > +
> > +  在mce-test中的一些便携式hwpoison测试程序，见下文。
> > +
> > +引用
> > +====
> > +
> > +http://halobates.de/mce-lc09-2.pdf
> > +       09年LinuxCon的概述演讲
> > +
> > +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git
> > +       测试套件（在tsrc中的hwpoison特定可移植测试）。
> > +
> > +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-inject.git
> > +       x86特定的注入器
> > +
> > +
> > +限制
> > +====
> > +- 不是所有的页面类型都被支持，而且永远不会。大多数内核内部对象不能被恢
> > +  复，目前只有LRU页。
> > +
> > +---
> > +Andi Kleen, 2009年10月
> > diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
> > index cc8d68b0cbb5..dd0b3d4c0ab8 100644
> > --- a/Documentation/translations/zh_CN/vm/index.rst
> > +++ b/Documentation/translations/zh_CN/vm/index.rst
> > @@ -27,12 +27,12 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
> >     free_page_reporting
> >     highmem
> >     frontswap
> > +   hwpoison
> >
> >  TODOLIST:
> >  * arch_pgtable_helpers
> >  * free_page_reporting
> >  * hmm
> > -* hwpoison
> >  * hugetlbfs_reserv
> >  * memory-model
> >  * mmu_notifier
> > --
> > 2.27.0
> >

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 05/12] docs/zh_CN: add vm overcommit-accounting translation
  2022-03-08 15:16   ` Alex Shi
@ 2022-03-14 12:03     ` yanteng si
  0 siblings, 0 replies; 21+ messages in thread
From: yanteng si @ 2022-03-14 12:03 UTC (permalink / raw)
  To: Alex Shi
  Cc: Jonathan Corbet, Alex Shi, Yanteng Si, Huacai Chen, Jiaxun Yang,
	Linux Doc Mailing List

Alex Shi <seakeel@gmail.com> 于2022年3月8日周二 23:16写道：
>
> On Sun, Mar 6, 2022 at 12:25 AM Yanteng Si <siyanteng01@gmail.com> wrote:
> >
> > Translate .../vm/overcommit-accounting.rst into Chinese.
> >
> > Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> > ---
> >  Documentation/translations/zh_CN/vm/index.rst |  2 +-
> >  .../zh_CN/vm/overcommit-accounting.rst        | 86 +++++++++++++++++++
> >  2 files changed, 87 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/translations/zh_CN/vm/overcommit-accounting.rst
> >
> > diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst
> > index 919e879b8167..2a3a93a4c050 100644
> > --- a/Documentation/translations/zh_CN/vm/index.rst
> > +++ b/Documentation/translations/zh_CN/vm/index.rst
> > @@ -30,6 +30,7 @@ TODO:待引用文档集被翻译完毕后请及时修改此处）
> >     hwpoison
> >     memory-model
> >     mmu_notifier
> > +   overcommit-accounting
> >
> >  TODOLIST:
> >  * arch_pgtable_helpers
> > @@ -37,7 +38,6 @@ TODOLIST:
> >  * hmm
> >  * hugetlbfs_reserv
> >  * numa
> > -* overcommit-accounting
> >  * page_migration
> >  * page_frags
> >  * page_owner
> > diff --git a/Documentation/translations/zh_CN/vm/overcommit-accounting.rst b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst
> > new file mode 100644
> > index 000000000000..1e3eae1338cb
> > --- /dev/null
> > +++ b/Documentation/translations/zh_CN/vm/overcommit-accounting.rst
> > @@ -0,0 +1,86 @@
> > +:Original: Documentation/vm/overcommit.rst
>
> Documentation/vm/overcommit-accounting.rst ?
ok!
>
> > +
> > +:翻译:
> > +
> > + 司延腾 Yanteng Si <siyanteng@loongson.cn>
> > +
> > +:校译:
> > +
> > +
> > +
> > +==============
> > +Overcommit审计
>
> overcommit -> 超量使用?
ok!
>
> > +==============
> > +
> > +Linux内核支持下列overcommit处理模式
> > +
> > +0
> > +       启发式overcommit处理。拒绝明显的地址空间overcommit。用于一个典型的系统。
> > +       它确保严重的疯狂分配失败，同时允许overcommit以减少swap的使用。在这种模式下，
> > +       允许root分配稍多的内存。这是默认的。
> > +1
> > +       总是overcommit。适用于一些科学应用。经典的例子是使用稀疏数组的代码，只是依赖
> > +       几乎完全由零页组成的虚拟内存
> > +
> > +2
> > +       不overcommit。系统提交的总地址空间不允许超过swap+一个可配置的物理RAM的数量
> > +       （默认为50%）。根据你使用的数量，在大多数情况下，这意味着一个进程在访问页面时
> > +       不会被杀死，但会在内存分配上收到相应的错误。
> > +
> > +       对于那些想保证他们的内存分配在未来可用而又不需要初始化每一个页面的应用程序来说
> > +       是很有用的。
> > +
> > +overcommit策略是通过sysctl  `vm.overcommit_memory` 设置的。
> > +
> > +可以通过 `vm.overcommit_ratio` （百分比）或 `vm.overcommit_kbytes` （绝对值）
> > +来设置超限数量。这些只有在 `vm.overcommit_memory` 被设置为2时才有效果。
> > +
> > +在 ``/proc/meminfo`` 中可以分别以CommitLimit和Committed_AS的形式查看当前
> > +的overcommit和提交量。
> > +
> > +陷阱
> > +====
> > +
> > +C语言的堆栈增长是一个隐含的mremap。如果你想得到绝对的保证，并在接近边缘的地方运行，
> > +你 **必须** 为你认为你需要的最大尺寸的堆栈进行mmap。对于典型的堆栈使用来说，这并
> > +不重要，但如果你真的非常关心的话，这就是一个值得关注的案例。
> > +
> > +
> > +在模式2中，MAP_NORESERVE标志被忽略。
> > +
> > +
> > +它是如何工作的
> > +==============
> > +
> > +overcommit是基于以下规则
> > +
> > +For a file backed map
>
> 对于文件映射
ok
>
> > +       | SHARED or READ-only   -       0 cost (该文件是映射而不是交换)
> > +       | PRIVATE WRITABLE      -       每个实例的映射大小
> > +
> > +For an anonymous or ``/dev/zero`` map
> 对于匿名或者/dev/zero 映射？
ok
>
> > +       | SHARED                        -       映射的大小
> > +       | PRIVATE READ-only     -       0 cost (但作用不大)
> > +       | PRIVATE WRITABLE      -       每个实例的映射大小
> > +
> > +Additional accounting
> 额外的计数
ok
>
> > +       | 通过mmap制作可写副本的页面
> > +       | 从同一池中提取的shmfs内存
> > +
> > +状态
> > +====
> > +
> > +*      我们核算mmap内存映射
> > +*      我们核算mprotect在提交中的变化
> > +*      我们核算mremap的大小变化
> > +*      我们的审计 brk
> > +*      审计munmap
> > +*      我们在/proc中报告commit 状态
> > +*      核对并检查分叉的情况
> > +*      审查堆栈处理/执行中的构建
> > +*      叙述SHMfs的情况
> > +*      实现实际限制的执行
> > +
> > +待续
> > +====
> > +*      帐户trace页（这很难）。
>
> ptrace 页计数？
ok!

Thanks,
Yanteng
>
> Thanks
> Alex
>
> > --
> > 2.27.0
> >

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-03-14 12:10 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-03-05 16:26 [PATCH 00/12] docs/zh_CN: add a little vm translation Yanteng Si
2022-03-05 16:26 ` [PATCH 01/12] docs/zh_CN: add vm frontswap translation Yanteng Si
2022-03-08 11:49   ` Alex Shi
2022-03-05 16:26 ` [PATCH 02/12] docs/zh_CN: add vm hwpoison translation Yanteng Si
2022-03-08 13:04   ` Alex Shi
2022-03-14 11:56     ` yanteng si
2022-03-05 16:26 ` [PATCH 03/12] docs/zh_CN: add vm memory-model translation Yanteng Si
2022-03-08 12:37   ` Alex Shi
2022-03-14 11:18     ` yanteng si
2022-03-05 16:26 ` [PATCH 04/12] docs/zh_CN: add vm mmu_notifier translation Yanteng Si
2022-03-08 15:02   ` Alex Shi
2022-03-05 16:26 ` [PATCH 05/12] docs/zh_CN: add vm overcommit-accounting translation Yanteng Si
2022-03-08 15:16   ` Alex Shi
2022-03-14 12:03     ` yanteng si
2022-03-05 16:26 ` [PATCH 06/12] docs/zh_CN: add vm page_frags translation Yanteng Si
2022-03-05 16:26 ` [PATCH 07/12] docs/zh_CN: add vm page_owner translation Yanteng Si
2022-03-05 16:26 ` [PATCH 08/12] docs/zh_CN: add vm page_table_check translation Yanteng Si
2022-03-05 16:26 ` [PATCH 09/12] docs/zh_CN: add vm remap_file_pages translation Yanteng Si
2022-03-05 16:26 ` [PATCH 10/12] docs/zh_CN: add vm split_page_table_lock translation Yanteng Si
2022-03-05 16:26 ` [PATCH 11/12] docs/zh_CN: add vm z3fold translation Yanteng Si
2022-03-05 16:26 ` [PATCH 12/12] docs/zh_CN: add vm zsmalloc translation Yanteng Si

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).