diff --git a/SUMMARY.md b/SUMMARY.md
index 38c4bb07243bdd2aee7a23d8a1c23b43edddbf04..5d4b747c30248eddda77fd51c3a92e92c860a898 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -5,6 +5,8 @@
 * [云原生场景](./cloud_native/README.md)
     * [面向云原生生态的操作系统发行版 LifseaOS](./cloud_native/lifseaos.md)
     * [跨云-边-端的只读文件系统 EROFS](./cloud_native/erofs.md)
+    * [数据库/JAVA等高性能场景中的内存优化](./cloud_native/hugetext.md)
+    * [跨处理器节点内存访问优化](./cloud_native/duptext.md)
 * [一云多芯硬件生态](./multi_arch/README.md)
     * [Intel SPR平台支持](./multi_arch/intel_spr_support.md)
     * [开源硬件 RISC-V 支持](./multi_arch/riscv.md)
diff --git a/cloud_native/duptext.md b/cloud_native/duptext.md
new file mode 100644
index 0000000000000000000000000000000000000000..c6c3b11c1f0182e3262c99254d1f7eab05faa94e
--- /dev/null
+++ b/cloud_native/duptext.md
@@ -0,0 +1,25 @@
+# 跨处理器节点内存访问优化
+
+tags: 云原生场景, Anolis8
+
+## 背景概述
+
+在新平台多节点大内存的趋势背景下，打开NUMA是必要的性能手段。随之而来的问题是，跨NUMA访问会引入性能开销。业务一般配合用户态任务调度，利用绑核等手段规避跨NUMA访问。但文件页跨节点访问不能很好解决。其中，代码段文件页跨节点访问的性能影响比较明显，对于数据库/存储等业务来说，甚至成为性能瓶颈；该性能影响在ARM平台上更为明显。
+
+现有的内核接口(例如NUMA Balancing)、用户态工具都不能很好地解决代码段的跨节点访问。
+
+## 技术方案: 代码多副本 (Duptext)
+
+我们给出代码多副本方案(Duptext)，执行流程如下图所示。
+
+![Hugetext 的整体架构和主要优化(绿色标记)](../materials/imgs/cloud_native/duptext/duptext_overview.jpg)
+
+Duptext主动检测代码段跨节点访问。在文件缺页以及主动映射流程中，检查当前需要映射的可执行文件页所属节点和当前进程运行节点是否一致。如果不一致，则在本地同步创建副本，并用副本建立此次映射。
+
+代码副本按需创建，在每个节点上通过基数树管理。考虑到代码段通常体积较小，Duptext引入的内存开销可控，利用空间换取时间。同时，Duptext提供整机粒度和Memcg粒度的开关，支持重点应用使能代码副本，支持整机回退，稳定性得到保障。
+
+## 应用场景及性能收益
+
+本地测试中，例如某ARM平台上MySQL代码段跨节点访问带来的性能下降可以达到-3% (无背景压力) ~ -22% (有背景压力)，应用Duptext之后，MySQL端到端性能都能达到本地访问的性能基线。
+
+真实业务场景中，例如某ARM平台上分布式块存储系统业务，Duptext可以带来最高16%端到端性能优化 (性能基线为默认状态下代码段跨节点的性能)。
diff --git a/cloud_native/hugetext.md b/cloud_native/hugetext.md
new file mode 100644
index 0000000000000000000000000000000000000000..1946fa0b87c7067b0d1d510a70d7391327cdfe48
--- /dev/null
+++ b/cloud_native/hugetext.md
@@ -0,0 +1,30 @@
+# 数据库/JAVA等高性能场景中的内存优化
+tags: 云原生场景, Anolis8
+
+## 背景概述
+
+在处理器内存缓存层级结构中，iTLB miss性能指标对访存优化至关重要，并且在ARM平台上优化效果更为明显。
+
+在数据库/JAVA 等高性能场景中，iTLB miss可以成为影响性能的主要因素，我们通过实验观察到iTLB miss引入的CPU停顿时间最高占任务运行时间的~13%。优化iTLB miss的手段很多，主要分为两类。一类是优化代码段布局，例如hfsort/gold linker、BOLT、 PGO，缺点是不通用；一类是使用大页映射代码段，例如静态大页 (hugetlbfs)、共享内存大页 (shmem)，缺点是调试信息缺失， 需要额外运维等。
+
+通用透明的方案需要基于文件透明大页来实现。社区Linux内核从5.4合入READ_ONLY_THP_FOR_FS特性，支持普通二进制文件的代码段部分映射文件透明大页；并通过写文件时清空文件缓存来规避写文件透明大页的问题。但仍有如下两个缺点。
+- 应用程序需要主动通过madvise系统调用来使能代码段映射文件透明大页；
+- 共享库、PIC/PIE(位置无关二进制文件)代码段的映射地址通常不能2M对齐，导致不能映射文件透明大页。
+
+## 技术方案: 透明代码大页(Hugetext)
+
+我们给出透明代码大页的方案(Hugetext)，提出四点优化和改进，如下图所示。
+1. 检测可执行文件加载/映射，分配地址2M对齐，自动使能普通二进制、共享库、PIC/PIE(位置无关二进制文件)的代码段映射文件透明大页；
+2. 检测匿名可执行代码 (例如JAVA code cache)，提供开关自动映射匿名透明大页；
+3. 相比普通透明大页，内核khugepaged线程优先整理可执行文件透明大页，达到加速效果；
+4. 对于大小不足2M的代码段，通过补齐映射地址空间，增加文件透明大页的覆盖率。
+
+![Hugetext 的整体架构和主要优化(绿色标记)](../materials/imgs/cloud_native/hugetext/hugetext_overview.jpg)
+
+## 应用场景及性能收益
+
+本地测试中，某ARM平台上数据库类业务(例如MySQL)，Hugetext可以提升性能5-12%；某ARM平台上JAVA类业务(例如 Spring)，Hugetext可以提升性能4-13%。
+
+真实业务场景中，例如某ARM平台上MySQL/PostgreSQL业务，Hugetext可以带来6+%的端到端性能提升。
+
+Hugetext特性也在Linux内核社区和Glibc社区回馈了开源补丁，增强了稳定性，修正了代码段地址映射问题。
diff --git a/materials/imgs/cloud_native/duptext/duptext_overview.jpg b/materials/imgs/cloud_native/duptext/duptext_overview.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..a35ad0bd62122dfce77a65f9bef778eaddf9fc09
Binary files /dev/null and b/materials/imgs/cloud_native/duptext/duptext_overview.jpg differ
diff --git a/materials/imgs/cloud_native/hugetext/hugetext_overview.jpg b/materials/imgs/cloud_native/hugetext/hugetext_overview.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..60b48aefabf596e84cca515df78dcbc409504503
Binary files /dev/null and b/materials/imgs/cloud_native/hugetext/hugetext_overview.jpg differ