diff --git a/TC_Project.yml b/TC_Project.yml
new file mode 100644
index 0000000000000000000000000000000000000000..7159efd963df02b46e6e4470c1ab0c14fda9bb7e
--- /dev/null
+++ b/TC_Project.yml
@@ -0,0 +1,54 @@
+projects:
+ - project_id: TC2024120201 # 项目id
+ repos:
+ - repo_name: anolis/cloud-kernel # 仓库
+ dir_or_files: # 仓库内文件或文件夹, 为空时表示所有目录
+ -
+ - repo_name: src-anolis-sig/cloud-kernel
+ dir_or_files:
+ -
+ - project_id: TC2024080201 # 知识库文档共建，项目 Sponsor：林生（阿里云），徐国振（浪潮信息）
+ repos:
+ - repo_name: https://gitee.com/anolis/anolis-kb # 仓库
+
+ - project_id: TC2024080205 # 龙蜥社区 AI 容器镜像商业参考实现建设，项目 Sponsor：宋凯（浪潮信息），王洪虎（龙芯），徐春梅(阿里云)
+ repos:
+ - repo_name: anolis/anolis-container
+
+ - project_id: TC2024080206 # 龙蜥社区 AI 容器组件 Pyhon Whl 软件仓建设，项目 Sponsor：宋凯（浪潮信息），王洪虎（龙芯），徐春梅(阿里云)
+ repos:
+ - repo_name: src-anolis-whl
+
+ - project_id: TC2024080202 # Anolis OS 7 YUM 源维护项目，项目 Sponsor：崔湛(统信)，庞训磊（阿里云）
+ repos:
+ - repo_name: https://gitee.com/anolis/anolis7.9els # 仓库
+
+ - project_id: TC2024080204 # [安全漏洞机制共建] 共建安全漏洞管理机制，项目 Sponsor：张世乐（阿里云），徐国振（浪潮信息），谈虎（中兴通讯），崔湛（统信软件），贺春妮（中科方德），段廷银（中科曙光），史建才（北京红旗），安全委员会，Distro SIG，Cloud Kernel SIG
+ repos:
+ - repo_name: https://gitee.com/src-anolis-os # group组下所有仓库
+
+ - repo_name: https://gitee.com/src-anolis-sig
+
+ - project_id: TC2024110201 # [龙芯架构支持] 发行版龙芯处理器支持，项目 Sponsor：王洪虎（龙芯中科），高畅（阿里云），LoongArch SIG，Distro SIG，Cloud Kernel SIG
+ repos:
+ - repo_name: https://gitee.com/src-anolis-os # group组
+
+ - repo_name: https://gitee.com/src-anolis-sig
+
+ - project_id: TC2024110202 # [申威架构支持] 发行版申威处理器支持，项目 Sponsor：崔巍(电科申泰），韩笑（阿里云），申威架构 SIG，Distro SIG，Cloud Kernel SIG
+ repos:
+ - repo_name: https://gitee.com/src-anolis-os # group组
+
+ - repo_name: https://gitee.com/src-anolis-sig
+
+ - project_id: TC2024110203 # [GNR架构支持] 发行版 Intel 处理器支持，项目 Sponsor：李崇（英特尔），尚旭春（阿里云），Xuchun（SIG 管理员）Intel Arch SIG，Distro SIG，Cloud Kernel SIG
+ repos:
+ - repo_name: https://gitee.com/src-anolis-os # group组
+
+ - repo_name: https://gitee.com/src-anolis-sig
+
+ - project_id: TC2024120201 # [海光四号架构支持] 发行版海光处理器支持，项目 Sponsor：李伟（海光信息），易兴睿（阿里云），Hygon Arch SIG，Distro SIG，Cloud Kernel SIG
+ repos:
+ - repo_name: https://gitee.com/src-anolis-os # group组
+
+ - repo_name: https://gitee.com/src-anolis-sig
\ No newline at end of file
diff --git "a/sig/AI/content/Bugzilla\347\263\273\347\273\237/Bugzilla\347\224\250\346\210\267\346\226\207\346\241\243.md" "b/sig/AI/content/Bugzilla\347\263\273\347\273\237/Bugzilla\347\224\250\346\210\267\346\226\207\346\241\243.md"
index 6076d9eb8468e7775018769f6bd3bad92d5ca670..0533529798d6e61d7980fc234ec3095ca7094bcc 100644
--- "a/sig/AI/content/Bugzilla\347\263\273\347\273\237/Bugzilla\347\224\250\346\210\267\346\226\207\346\241\243.md"
+++ "b/sig/AI/content/Bugzilla\347\263\273\347\273\237/Bugzilla\347\224\250\346\210\267\346\226\207\346\241\243.md"
@@ -6,7 +6,7 @@ Bugzilla是一个缺陷管理系统，可以用来管理Bug，也可以用来管
## 二. Bug生命周期
-- **2.1 新建Bug**
+- **2.1 新建Bug**
- **2.1.1 路径**
首页->New/File a Bug->Select a classification->Select a product->Bug创建页面。具体如下：首先，在首页点击New或File a Bug按钮，进行创建Bug。
diff --git "a/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/...Pstore\345\211\215\347\253\257DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md" "b/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/...Pstore\345\211\215\347\253\257DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md"
index d00e1b42c34c3055a84dfdfe4e134dbab1df1f6d..8682851da2ed6e492c8fcc12c8ac2331a1712193 100644
--- "a/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/...Pstore\345\211\215\347\253\257DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md"
+++ "b/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/...Pstore\345\211\215\347\253\257DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md"
@@ -203,7 +203,8 @@ pstore dmesg主要工作流程如下：
（5）调用后端的写函数，将record写入相应的后端设备
-
+加点内容
+算22332
diff --git "a/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/Pstore\345\211\215\347\253\257\357\274\232DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md" "b/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/Pstore\345\211\215\347\253\257\357\274\232DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md"
index d00e1b42c34c3055a84dfdfe4e134dbab1df1f6d..d5f3a1ba76f702e35bea6cc937f08a58227bc95d 100644
--- "a/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/Pstore\345\211\215\347\253\257\357\274\232DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md"
+++ "b/sig/AI/content/\345\206\205\346\240\270\350\260\203\346\265\213/Pstore\345\211\215\347\253\257\357\274\232DMESG_\344\273\243\347\240\201\345\210\206\346\236\220.md"
@@ -202,6 +202,8 @@ pstore dmesg主要工作流程如下：
（5）调用后端的写函数，将record写入相应的后端设备
+wwqwq
+
diff --git "a/sig/AI/content/\346\234\210\346\212\245/202212.md" "b/sig/AI/content/\346\234\210\346\212\245/202212.md"
index 88250c901b0988fd3ca405387b290d62c3ad6602..5ace9b5cdb18d6179cf6200f9b7b4cb5d6a49112 100644
--- "a/sig/AI/content/\346\234\210\346\212\245/202212.md"
+++ "b/sig/AI/content/\346\234\210\346\212\245/202212.md"
@@ -80,3 +80,6 @@
# 运营活动
- [浪潮信息正式发布基于龙蜥 Anolis OS 的服务器操作系统 Inspur KOS](https://openanolis.cn/news/726244284765327879)。
- 于2022.12.24 举办了“[龙蜥走进系列活动之走进浪潮信息 MeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4MTMyMTUwMQ==&mid=2247510368&idx=1&sn=95a1d511b32670f8388745682483046a&chksm=cf655a12f812d30494be938d7bf8a46b7244711c8fb75f44e8379ab261b1fd4aeb1c8bb0805e&scene=21#wechat_redirect)"，并成立了浪潮信息龙蜥联合实验室，致力于共建龙蜥社区的软硬件兼容性生态、标准建设和技术创新等。
+
+
+TC2024080403
\ No newline at end of file
diff --git "a/sig/AI/content/\346\234\210\346\212\245/2022121.md" "b/sig/AI/content/\346\234\210\346\212\245/2022121.md"
index 9ad98f224496529eddaf50dc615ca397325f8c89..9718d343b780e08f1638b51b2b4574014e947b74 100644
--- "a/sig/AI/content/\346\234\210\346\212\245/2022121.md"
+++ "b/sig/AI/content/\346\234\210\346\212\245/2022121.md"
@@ -1 +1 @@
-xcvxcvxcvxcbcvvb
\ No newline at end of file
+xcvxcvxcvxcbcvvbasdfsda
\ No newline at end of file
diff --git "a/sig/AI/content/\346\234\210\346\212\245/202301.md" "b/sig/AI/content/\346\234\210\346\212\245/202301.md"
index 85bbb428461066b1774f93d5ede99390bf2bc702..154fa40ad1d79cabc278e4bf3dcbffdfb9c87047 100644
--- "a/sig/AI/content/\346\234\210\346\212\245/202301.md"
+++ "b/sig/AI/content/\346\234\210\346\212\245/202301.md"
@@ -1,5 +1,12 @@
# 整体进展
+
+
+修改文件20202202-102-1201-1210201-1-
+
+
+
+
- 发布 ANCK 5.10-013 版本。
- 确定KABI机制整体方案。
- 浪潮信息龙蜥联合实验室的工作事项更新。
diff --git "a/sig/AI/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md" "b/sig/AI/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md"
index 30020428d41c0b35e0eb225c6a3b4a4a06f385a6..4882c4cd488bdd8646accb120e61f294e957c864 100644
--- "a/sig/AI/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md"
+++ "b/sig/AI/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md"
@@ -5,3 +5,13 @@
+ 具体进展：SIG 该月项目的详细进展，分别展开细节。
+ 重要议题: SIG 该月讨论的重要议题。
+ 运营活动: SIG 该月发生的运营活动。
+
+
+66666666666666666666666666666666666666666666666
+
+
+04444433333333333333333333333333333333--
+
+
+ 不写项目编码
+ ------------------------
\ No newline at end of file
diff --git "a/sig/AI/content/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244\350\257\276\347\250\213\346\216\245\345\205\245\346\214\207\345\257\274.md" "b/sig/AI/content/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244\350\257\276\347\250\213\346\216\245\345\205\245\346\214\207\345\257\274.md"
index 757eaada8906bad388c372d11dcd3402fedfad3a..d13161ade3d8431eaeddc633ac4bdedc72a2e099 100644
--- "a/sig/AI/content/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244\350\257\276\347\250\213\346\216\245\345\205\245\346\214\207\345\257\274.md"
+++ "b/sig/AI/content/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244/\351\276\231\350\234\245\345\256\236\351\252\214\345\256\244\350\257\276\347\250\213\346\216\245\345\205\245\346\214\207\345\257\274.md"
@@ -33,3 +33,6 @@
六、提交审核之后等待管理员审核，管理员审核通过之后在实验室课程中心就能看到了
以上就是龙蜥实验室创作中心创作课程的完整过程，如使用过程中有问题，欢迎联系[基础设施 SIG 组](https://openanolis.cn/sig/SIG-Infra)。
+
+
+加点内容
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/a.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/a.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/a.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/acbsds.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/acbsds.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/acbsds.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/dvdvdv.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/dvdvdv.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/dvdvdv.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/a.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/a.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/a.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/aA.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/aA.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/aA.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/aaa.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/aaa.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/aaa.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/abc.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/abc.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/abc.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/gddgdfd\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/gddgdfd\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/gddgdfd\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/a.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/a.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/a.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/c.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/c.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test000/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/c.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/aaa.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/aaa.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/aaa.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abc.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abc.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abc.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abcd/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\243.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abcd/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\243.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abcd/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\243.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abcd/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\24302.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abcd/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\24302.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/abcd/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\24302.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/eeeeeee.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/eeeeeee.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/eeeeeee.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\243.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\243.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\243.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2433.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2433.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2433.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2434.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2434.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2434.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2435.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2435.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2435.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2436.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2436.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2436.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2437.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2437.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2437.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2438.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2438.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2438.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\243.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\243.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\243.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\24302.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\24302.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2252\346\226\207\346\241\24302.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253\346\226\207\346\241\243.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253\346\226\207\346\241\243.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253\346\226\207\346\241\243.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253\346\226\207\346\241\24302.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253\346\226\207\346\241\24302.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2253\346\226\207\346\241\24302.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\225.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\225.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\225.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\22510.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\22510.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\22510.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2252.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2252.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2252.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2254.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2254.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2254.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2255.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2255.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2255.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2256.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2256.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2256.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2257.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2257.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2257.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2258.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2258.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2258.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2259.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2259.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test001/\346\200\247\350\203\275\346\265\213\350\257\2259.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/a.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/a.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/a.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/aA.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/aA.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/aA.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/aaa.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/aaa.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/aaa.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/abc.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/abc.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/abc.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/tttfsdfsdf.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/tttfsdfsdf.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/tttfsdfsdf.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/abc.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/abc.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/abc.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/gddgdfd\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/gddgdfd\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/gddgdfd\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\243.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\243.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\243.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2430.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2430.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2430.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2431.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\344\272\214\347\272\247\347\233\256\345\275\225\346\226\207\346\241\2432.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\347\233\256\345\275\225\346\226\207\346\241\243.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\347\233\256\345\275\225\346\226\207\346\241\243.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\225/\347\233\256\345\275\225\346\226\207\346\241\243.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/a.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/a.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/a.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/c.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/c.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ec8e22ac006bf2e176d9e7f7890c4f2de8420eaf
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/test002/\344\272\214\347\272\247\347\233\256\345\275\225\346\265\213\350\257\2250/c.md"
@@ -0,0 +1,205 @@
+# 背景
+代码大页特性将应用程序代码段 (.text) 通过file THP映射，减少TLB entry开销，以此减低整个系统中TLB entry的资源竞争。对于MySQL、JAVA等应用，能显著减少iTLB miss，提升E2E性能。下面会采用hugetext来代表代码大页。
+
+
+我们在本地基准测试以及业务真实压力测试都验证了hugetext性能效果。对于数据库类业务（例如 MySQL），x86物理机/虚拟机上hugetext提升性能2\~4%，ARM物理机/虚拟机上hugetext提升性能6\~10%；
+
+
+本文档主要用于展示**透明代码大页**使用、mysql相关测试数据，平台涉及x86和arm物理机。最后将代码大页、THP以及4k在mysql上进行性能对比。
+
+作者：王荣巍（雨庭） 徐宇（弃余） 邓刚（据德）
+
+# hugetext使用
+
+## 使用开关
+
+- 启动参数
+
+打开：hugetext=1 or 2 or 3
+关闭：缺省即为关闭
+
+
+
+- sysfs接口
+
+仅打开二进制和动态库大页：echo 1 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+仅打开可执行匿名大页：echo 2 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+打开以上两类大页：echo 3 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+关闭：echo 0 > /sys/kernel/mm/transparent\_hugepage/hugetext\_enabled
+
+
+## 回退
+在打开hugetext\_enabled后，若关闭hugetext\_enabled并且完全消除hugetext\_enabled影响，可以下面几种方式：
+
+- 清理整个系统的page cache：echo 3 > /proc/sys/vm/drop\_caches
+- 清理单个文件的page cache：vmtouch -e /\/target
+
+
+
+## 注意事项
+打开、关闭并不意味着立即合并、拆散大页，hugetext是异步的。
+如果一段代码曾经被整理成大页，即使关闭hugetext功能，还是会大页映射。
+
+
+在测试性能时，为了消除这些影响，可以通过 `echo 3 > /proc/sys/vm/drop\_caches` 来回收整理的大页，以保证下次是普通页映射。
+
+
+想确认代码段是否大页映射，可以通过 `grep FilePmdMapped /proc/$(pidof mysqld)/smaps` 来确认。
+
+# mysql测试准备
+
+创建用户以及修改密码：
+```c
+mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '123';
+```
+
+
+创建数据库：
+```
+CREATE DATABASE hugepages;
+show databases;
+```
+所创建的数据库hugepages需要与下面的步骤保持一直。
+
+
+开始为创建的数据库准备数据，执行以下命令（**进行该步骤前需要安装sysbench**）：
+```
+sysbench --test=/usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=200 --oltp-table-size=100000 --report-interval=2 prepare
+```
+其中，prepare表示准备数据，在的sbtest库生成测试数据，
+创建200张表，每张表10万条数据，每2秒显示一次报告。
+
+# 代码大页 - mysql数据库测试
+
+下面是代码大页的测试数据。
+
+## arm平台mysql性能测试
+
+测试说明：
+测试过程中需要对mysqld进行**绑核**，并显示指定内存分配节点为local node。
+
+
+测试命令：
+sysbench /usr/local/share/sysbench/tests/include/oltp\_legacy/oltp.lua --mysql-db=hugepages --mysql-host=localhost --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --time=300 --threads=1 --report-interval=5 run
+
+
+
+测试过程中，mysql并发数分别是1、8（25%）、16（50%）、32（100%）。测试结果与普通的4K代码页数据对比如下：
+
+
+
+**图1：arm平台mysql TPS测试数据对比**
+
+
+上图TPS对比可以看出：代码大页的性能始终高于普通的代码页。关于这张图中其他的结论，还有：
+
+- 并发数为1时，外在的影响因素最小，此时，代码大页相比普通代码页，性能提升大约在6.9%；
+- 并发数8、16基本可以保证没有cpu的竞争，代码大页的性能提升大约也在6.5%以上；
+- 并发数32时，由于总核数为32，存在于其他应用竞争cpu，所以TPS较低于前面的测试结果。但是代码大页的鲁棒性更好，此时相比普通代码页，性能提升大约在11%左右；
+
+另外，还有RT的对比，如下图：
+
+
+
+**图2：arm平台mysql RT数据对比**
+
+
+RT的数据主要是前95%的请求的最大响应时间（**95th percentile**）。代码大页在RT上的表现与图1一致，大约提升在5.7%~11.4%之间。
+
+## x86平台mysql性能测试
+
+测试方法以及测试数据与arm平台一致。
+
+该测试主要在Intel(R) Xeon(R) Platinum 8163平台下完成。
+
+TPS、RT对比图如下：
+
+
+
+**图3（a、b）为TPS、RT对比图**
+
+
+由于TLB硬件的差异，代码大页在x86和arm上性能提升存在差异，根据图6（a、b）中的测试数据，代码大页在x86上，对TPS的提升大致在3%-5之间，在RT上大致有5%-7.5%的收益。
+
+
+除intel Xeon平台，在海光的机器上对mysql数据库+代码大页进行了性能测试。
+
+
+
+**图4 海光平台测试数据。图左为并发数为1的测试（上为普通，下为开启hugetext），图右为并发数为4的测试数据**
+
+
+上图代码大页性能结论为：单核提升6.5%，4并发数提升3.9%；
+
+## 微架构测试数据
+
+除前面展示的mysql数据库中的TPS和RT数据，我们也记录了在测试过程中iTLB miss，以及换算后的iTLB MPKI数据。
+x86和arm平台的数据如下：
+
+
+x86平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图5 x86平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- 从iTLB miss的数据看，代码大页相比4k代码页大约下降了1.5-2.3倍左右；
+- 从iTLB MPKI的数据看，代码大页相比4k代码页大约下降了1.6-2.3倍之间，与iTLB miss效果相似；
+
+测试iTLB MPKI使用的工具可以从下面的链接获取：
+https://github.com/intel/iodlr
+
+arm平台下的iTLB miss和iTLB MPKI数据：
+
+
+
+**图6 arm平台使用代码大页前后iTLB miss和iTLB MPKI数据对比图**
+
+
+上图数据显示：
+
+- mysql使用代码大页后，iTLB miss大约下降了10倍左右，数值大小从原来的1%下降到0.08%左右；
+- 在iTLB MPKI上，大约下降了6倍左右；
+
+**此外，可以看出在使用代码大页后，性能提升存在平台差异。图6和图7的iTLB miss差异主要是x86和arm的TLB entry差异。**
+
+## 代码大页 vs THP和4k
+
+这里将代码大页和目前比较熟知的THP进行对比，对比中将4k测试数据作为baseline。
+
+对比数据主要包括mysql单线程、4线程和8线程测试。数据如下：
+
+**图7 arm虚拟机中代码大页、THP和4k baseline数据对比**
+
+
+在图7中最后一列为性能与4k base相比提升的百分比，如代码大页和THP在单线程测试中，相比4k页，性能提升分别是12.7%和4.47%（本数据为虚拟机下测试数据，数值大小不能代表物理机下测试数据）。
+
+
+根据图7，可以大致得出以下结论：
+**代码大页的性能以及稳定性远优于anon THP；其性能存在以下规律：**
+**收益：代码大页 > anon THP > 4k**
+
+# 代码大页 - 达梦数据库测试
+
+达梦数据库安装测试文档：https://openanolis.cn/sig/third\_software\_compatibility/doc/390232652013568029
+
+下图为在x86 skylake平台上，关闭THP，分别设置hugetext=0,1或者2对达梦数据库进行测试：
+
+
+**图8 代码大页+达梦数据库性能测试对比**
+
+
+根据图中的数据，大致可以得出以下结论：
+
+（1）在x86 skylake平台上，当磁盘I/O利用率峰值在94%左右时，hugetext对于达梦数据库的提升大约在3.86%左右（如图最后一行数据显示）；
+
+（2）当磁盘I/O成为瓶颈，利用率100%，代码大页无法提升性能；
+
+
+
+
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/ToneAgent\347\274\226\350\257\221\346\211\223\345\214\205\346\211\213\345\206\214.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/ToneAgent\347\274\226\350\257\221\346\211\223\345\214\205\346\211\213\345\206\214.md"
new file mode 100644
index 0000000000000000000000000000000000000000..0949b8e70e5300f1cf752ca0259c1d30317b932b
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/ToneAgent\347\274\226\350\257\221\346\211\223\345\214\205\346\211\213\345\206\214.md"
@@ -0,0 +1,63 @@
+# 1. ToneAgent编译
+
+## 1.1 环境准备
+Go 1.17 及以上版本（[下载地址](https://go.dev/dl/)）
+
+## 1.2 下载ToneAgent
+ git clone git@gitee.com:anolis/tone-agent.git
+ cd tone-agent
+
+## 1.3 编译
+`-o` 后面是二进制的名称
+
+### 1.3.1 编译 AMD64的二进制
+ GOOS=linux GOARCH=amd64 go build -o toneagent-amd64-v102
+
+### 1.3.2 编译 ARM 的二进制
+ GOOS=linux GOARCH=arm64 go build -o toneagent-amd64-v102
+
+# 2. Linux环境二进制打包
+
+## 2.1 RPM包制作
+
+### 2.1.1 RPM环境准备
+ sudo su -c bash # 使用bash
+ yum install rpmdevtools rpmdevtools # 安装rpm打包工具
+
+### 2.1.2 打包RPM包
+ rpmdev-setuptree # 创建目录，会在用户目录下创建rpmbuild文件夹 ～/rpmbuild
+ cd # 返回用户目录
+ vi rpmbuild/SPEC/toneagent.spec # 修改创建spec的模板文件
+ mkdir rpmbuild/BUILDROOT/toneagent-0.0.1-AMD
+ cp ${二进制路径} rpmbuild/BUILDROOT/toneagent-0.0.1-AMD/ # 拷贝二进制到RPM目录
+ cd rpmbuild/SPEC/
+ rpmbuild -bb toneagent.spec # 构建rpm包
+
+### 2.1.3 RPM安装及启动
+ sudo yum -y install ${toneagent包位置} # 安装
+ sudo systemctl start toneagent # 启动
+
+## 2.2 DEB包制作
+
+### 2.1.1 环境准备
+ sudo apt instsll -y dpkg # 使用二进制打包，只需要安装这个包
+ sudo apt install -y dpkg build-essential devscripts quilt dh-make git # 扩展安装
+
+### 2.1.2 打包DEB包
+ mkdir toneagent.work
+ cd toneagent.work
+ mkdir -pv toneagent_0.0.1_amd64/{DEBIAN,bin}
+ cp ${tone-agent二进制} toneagent_0.0.1_amd64/bin/
+ echo "Package: toneagent
+ Version: 1.0
+ Architecture: arm
+ Maintainer: alibaba
+ Installed-Size: 100
+ Depends:
+ Priority: optional
+ Description: toneagent for SUNXI devices (A10,A20 ...),example is Cubieboard.
+ " >> toneagent_0.0.1_amd64/DEBIAN/control
+ dpkg -b toneagent_0.0.1_amd64 toneagent_0.0.1_amd64.deb
+
+### 2.1.3 DEB安装
+ dpkg -i toneagent_0.0.1_amd64.deb
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/aest.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/aest.md"
new file mode 100644
index 0000000000000000000000000000000000000000..9dca95d406a94bcd351308487dead32fe19c01a1
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/aest.md"
@@ -0,0 +1,16 @@
+HCT密码计算套件的目录结构如下：
+阿斯顿法师打发斯蒂芬
+44444444444444444444444444444444444444444444444444444
+hygon-devkit/
+
+ ├─ hct
+ ├──pkg
+ │ ├── hct_1.0.0.20230224_rc
+ │ ├── hct_1.0.1.20230512_rc
+ │ └── hct_1.1.0.20230730_rc
+ │
+ └── README.md
+
+\* pkg目录：内含各版本hct密码计算套件。
+
+\* README.md文件：有关HCT的简单情况。
\ No newline at end of file
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/test.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/test.md"
new file mode 100644
index 0000000000000000000000000000000000000000..9dca95d406a94bcd351308487dead32fe19c01a1
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/test.md"
@@ -0,0 +1,16 @@
+HCT密码计算套件的目录结构如下：
+阿斯顿法师打发斯蒂芬
+44444444444444444444444444444444444444444444444444444
+hygon-devkit/
+
+ ├─ hct
+ ├──pkg
+ │ ├── hct_1.0.0.20230224_rc
+ │ ├── hct_1.0.1.20230512_rc
+ │ └── hct_1.1.0.20230730_rc
+ │
+ └── README.md
+
+\* pkg目录：内含各版本hct密码计算套件。
+
+\* README.md文件：有关HCT的简单情况。
\ No newline at end of file
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/test2.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/test2.md"
new file mode 100644
index 0000000000000000000000000000000000000000..9dca95d406a94bcd351308487dead32fe19c01a1
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/test2.md"
@@ -0,0 +1,16 @@
+HCT密码计算套件的目录结构如下：
+阿斯顿法师打发斯蒂芬
+44444444444444444444444444444444444444444444444444444
+hygon-devkit/
+
+ ├─ hct
+ ├──pkg
+ │ ├── hct_1.0.0.20230224_rc
+ │ ├── hct_1.0.1.20230512_rc
+ │ └── hct_1.1.0.20230730_rc
+ │
+ └── README.md
+
+\* pkg目录：内含各版本hct密码计算套件。
+
+\* README.md文件：有关HCT的简单情况。
\ No newline at end of file
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/\345\257\271\345\244\226\346\234\215\345\212\241API.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/\345\257\271\345\244\226\346\234\215\345\212\241API.md"
new file mode 100644
index 0000000000000000000000000000000000000000..6be2fe13cbb6e50e1bf41c425b239231eda209e8
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/\345\257\271\345\244\226\346\234\215\345\212\241API.md"
@@ -0,0 +1 @@
+参考文档：https://tone.openanolis.cn/help_doc/7
\ No newline at end of file
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/\346\265\213\350\257\225\345\245\227\344\273\266\351\233\206\346\210\220\346\211\213\345\206\214.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/\346\265\213\350\257\225\345\245\227\344\273\266\351\233\206\346\210\220\346\211\213\345\206\214.md"
new file mode 100644
index 0000000000000000000000000000000000000000..67b07c6d8e8470eef075cf75048ba3f4036edeaa
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\345\274\200\345\217\221\346\211\213\345\206\214/\346\265\213\350\257\225\345\245\227\344\273\266\351\233\206\346\210\220\346\211\213\345\206\214.md"
@@ -0,0 +1,282 @@
+# tone-cli介绍
+tone-cli主要用于测试套件（testsuite）的调度及运行。
+
+# 代码仓库
+https://gitee.com/anolis/tone-cli
+
+# 测试套件构成
+测试套件主要由套件本身和集成脚本构成，其中：
+
+- 测试套件可以存放于gitee或其他代码仓库，也可以是一个系统中已经包含的命令
+- 集成脚本由两部分构成：
+ - 适配脚本
+ - 测试套配置文件
+
+# 测试套件集成
+
+## 测试配置文件
+测试配置文件位于`$TONE_ROOT/conf`目录下，与适配脚本一起为测试套件服务。
+
+为了便于组织，当前根据测试类别分为`functional`，`performance`和`stress`。
+
+测试配置文件主要用于描述测试的参数，以netperf为例：
+
+ test IP runtime send_size
+ TCP_RR ipv4 60s Na
+ TCP_RR ipv4 60s 16K
+ TCP_CC ipv4 60s Na
+ TCP_CRR ipv4 60s Na
+ ...
+
+第一行描述为变量名，后续行描述的是变量的值。tone-cli会将测试套配置文件按照配置进行执行：
+
+ $ tone list netperf
+ test IP runtime send_size testconf
+ TCP_RR ipv4 60 None netperf:test=TCP_RR,IP=ipv4,runtime=60s
+ TCP_RR ipv4 60 16K netperf:test=TCP_RR,IP=ipv4,runtime=60s,send_size=16K
+ TCP_CC ipv4 60 None netperf:test=TCP_CC,IP=ipv4,runtime=60s
+ TCP_CRR ipv4 60 None netperf:test=TCP_CRR,IP=ipv4,runtime=60s
+在后续的脚本中，conf中的变量会以参数形式传递给适配脚本。
+
+> 注：
+>
+> - 没有任何变量的测试套，仍然需要创建对应名称的配置文件，保持内容为空
+> - 对于某个参数，如netperf的send_size，在某些状况下不需要传入参数，则可以置为NA
+
+## 适配脚本
+
+测试套件适配脚本需要存放于`$TONE_ROOT/tests`目录下，创建工具对应的目录，如`$TONE_ROOT/tests/netperf`。
+
+tone-cli将测试定义为以下几个阶段，可以根据需要来决定是否需要对应的阶段：
+
+- 测试套件获取
+- 测试套件编译安装
+- 测试执行
+- 结果处理
+- 测试套件卸载
+
+适配脚本需要最少包含`install.sh`，`run.sh`和`README.md`，其中：
+
+- install.sh: 定义测试套件获取、依赖包、测试套件编译及安装
+- run.sh: 定义测试执行过程，结果处理方式
+- README.md: 测试套件必要说明
+
+其他脚本可以根据需要决定，如：将结果处理脚本单独编写，在run.sh中加以引用
+
+### 测试套件获取
+
+当前支持通过URL下载或git方式获取对应的测试套：
+
+| 方式| 参数 | 说明 |举例 |
+| :--:| :---: | :---: |:---: |
+|URL下载 |WEB_URL |测试套下载地址 |WEB_URL=“https://gitee.com/anolis/tone-cli/repository/archive/master.zip”|
+|GIT仓库 |GIT_URL |git仓库地址 |GIT_URL="https://gitee.com/mirrors_HewlettPackard/netperf.git"|
+| |BRANCH |git分支| BRANCH="netperf-2.7.0"|
+
+tone-cli将根据提供的`WEB_URL`，`GIT_URL`，`BRANCH`等信息拉取对应的源代码
+
+### 举例：
+
+`netperf/install.sh`
+
+ GIT_URL="https://gitee.com/mirrors_HewlettPackard/netperf.git"
+ BRANCH="netperf-2.7.0"
+
+### 测试套件编译安装
+
+tone-cli提供的标准安装方式由以下几步：
+
+- 执行安装前额外的操作：extract_src
+- 安装依赖包：install_pkg
+- 编译：build
+- 安装：install
+
+**extract_src**
+
+用于在安装依赖包之前进行必要的准备，如centos安装epel源：
+
+ extract_src()
+ {
+ logger yum install -y epel-release
+ }
+
+**install_pkg**
+
+绝大部分状况下，不需要重写install_pkg的方法，而仅通过设置DEP_PKG_LIST的变量，tone-cli将自动进行依赖包安装。如netperf/install.sh：
+
+ DEP_PKG_LIST="automake gcc texinfo"
+
+**build和install**
+
+通常状况，build和install都需要根据测试套件进行重写。以netperf为例：
+
+ build()
+ {
+ local configure_flags=(
+ --prefix="$TONE_BM_RUN_DIR"
+ )
+ if [ "$(/usr/bin/arch)" = aarch64 ]; then
+ configure_flags+=('--build=aarch64-unknown-linux-gnu')
+ fi
+
+ export CFLAGS="-fno-strict-aliasing -fcommon"
+
+ ./autogen.sh
+ ./configure "${configure_flags[@]}"
+ make
+ }
+
+ install()
+ {
+ make install-exec
+ }
+### 测试执行
+
+测试执行被定义在`run.sh`中，主要的步骤有：
+
+- 测试准备：setup
+- 测试执行：run
+- 测试拆除：teardown
+
+以netperf为例，netperf测试可以划分为：
+
+- 启动netserver
+- 使用netperf命令进行测试
+- 拆除netserver
+
+**setup**
+
+netperf测试中，netserver启动主要逻辑为：
+
+- 判断是否设置了$SERVER，如果已设置，则认为netserver将在对应的server上执行
+- 启动netserver，启动netserver的主要逻辑在netserver.sh中体现
+
+ setup()
+ {
+ [ -n "$SERVER" ] && server=${SERVER%% *} || server=localhost
+ echo "Run netserver on host: $server"
+
+ if [ "$server" = localhost ]; then
+ source "$TONE_BM_SUITE_DIR"/netserver.sh
+ else
+ ssh $server "TONE_ROOT=$TONE_ROOT TONE_BM_RUN_DIR=$TONE_BM_RUN_DIR IP=$IP server=$server $TONE_BM_SUITE_DIR/netserver.sh"
+ fi
+ }
+
+**run**
+
+netperf测试套的执行逻辑，主要根据测试套件配置中的参数组合，设置netperf命令行参数以执行测试
+
+> 注：
+>
+> 在执行命令时，使用logger方法将netperf命令行输出写入对应的日志文件中，以备后续进行结果处理
+
+ run()
+ {
+ export PATH="$TONE_BM_RUN_DIR"/bin:$PATH
+
+ [ -n "$send_size" ] && test_options="-- -m $send_size"
+
+ opt_ip=
+ [ "$IP" = 'ipv4' ] && opt_ip='-4'
+ [ "$IP" = 'ipv6' ] && opt_ip='-6'
+ base_cmd="netperf $opt_ip -t $test -c -C -l $runtime -H $server $test_options"
+
+ # check online cpus with cpu_affinity set on multi-processor machine
+ if [ "$server" = localhost ] && [ "$(nproc)" -gt 1 ]; then
+ check_oneline_cpu
+ # the last cpu is reservered for netserver if test on single node
+ cpu_online_num=$((cpu_online_num - 1))
+ cpu_online_tpy=$(echo "$cpu_online_tpy" | awk '{$NF=""; print $0}')
+ cpu_x=$((1 % cpu_online_num))
+ [ "$cpu_x" -eq 0 ] && cpu_x=$cpu_online_num
+ mycpu=$(echo "$cpu_online_tpy" | awk -v n=$cpu_x '{print $n}')
+ test_cmd="taskset -c $(echo "$mycpu" | cut -d- -f3) $base_cmd"
+ echo "run netperf on cpu: $(echo "$mycpu" | cut -d- -f3),"\
+ "socket: $(echo "$mycpu" | cut -d- -f1),"\
+ "core_id: $(echo "$mycpu" | cut -d- -f2)"
+ else
+ test_cmd="$base_cmd"
+ fi
+
+ logger $test_cmd &
+ logger wait
+ }
+
+**teardown**
+
+netperf的teardown阶段，主要通过执行pkill命令杀死netserver进程
+
+ teardown()
+ {
+ pkill netserver
+ }
+
+**结果处理**
+tone-cli当前规定的结果规范为`key: value`，所以只要符合这个输出规范，对应的结果会被收集并存储。
+
+以netperf为例，其结果处理的`parse()`调用了一个awk脚本：
+
+ #!/usr/bin/awk -f
+
+ /^Size.*Okay.*Throughput.*Demand$/ {
+ unit = "Mbps1"
+ next
+ }
+
+ /^Size.*Throughput.*remote$/ {
+ unit = "Mbps2"
+ next
+ }
+
+ /^bytes.*secs.\s+per sec/ {
+ unit = "tps"
+ next
+ }
+
+ $8 && $0 ~ /^[ \t0-9.]+$/ {
+ if ( unit == "Mbps1" ) {
+ printf("Throughput_Mbps: %s\n",$(NF-2))
+ }
+ else if ( unit == "Mbps2" ) {
+ printf("Throughput_Mbps: %s\n",$5)
+ }
+ else{
+ printf("Throughput_%s: %s\n",unit,$6)
+ }
+ }
+
+执行完毕后会输出：
+
+ Throughput_tps: 91336.30
+
+# 公共变量
+tone-cli提供了多个公共变量用于在测试集成时使用
+
+## 测试套配置文件
+
+|变量名称| 用途| 举例|
+|:--:|:--:|:--:|
+|nr_task |设置使用的线程数，可以使用百分比形式表示，当设置为百分比时，框架会根据当前测试机CPU数量进行计算 |nr_task=1, nr_task=50%|
+|cpu_affinity |设置CPU绑定| cpupin|
+
+## 测试套适配脚本
+
+|变量名称| 用途| 举例|
+|:--:|:--:|:--:|
+|$TONE_BM_CACHE_DIR |测试套件cache目录| /tmp/tone/cache/netperf|
+|$TONE_BM_BUILD_DIR| 测试套件build目录| /tmp/tone/build/netperf|
+|$TONE_BM_RUN_DIR |测试套件run目录，可以将测试套件安装于该目录中，而不用安装到系统目录下| /tmp/tone/run/netperf|
+|$TONE_BM_RESULT_DIR |测试套件结果存放目录 |/tmp/tone/result/netperf|
+|$TONE_CURRENT_RESULT_DIR |当次运行时的结果存放目录| /tmp/tone/result/netperf/1|
+|$TONE_BM_SUITE_DIR |测试套件脚本目录| /tmp/tone/tests/netperf|
+
+# 公共函数
+
+tone-cli提供一些公共函数已方便脚本编写，公共函数主要归档于$TONE_ROOT/lib目录下，在编写脚本时可以按需引入。常用的函数有：
+
+|函数名| 文件 |用途 |举例|
+|:--:|:--:|:--:|:--:|
+|logger |lib/common.sh |记录日志 |logger netperf -t TCP_RR|
+|set_cpu_affinity_server |lib/cpu_affinity.sh |设置服务端CPU绑核，会将server绑定在最后一个CPU核上，注意，需要通过server_cmd变量进行传递 |server_cmd="netserver" [ -n "$cpu_affinity" ] && set_cpu_affinity_client logger ${server_cmd}|
+|set_cpu_affinity_client |lib/cpu_affinity.sh| 设置客户端CPU绑核，会将client绑定在第一个CPU核上，注意，需要通过client_cmd进行传递 |client_cmd="netperf -t TCP_RR" [ -n "$cpu_affinity" ] && set_cpu_affinity_client logger ${client_cmd}|
\ No newline at end of file
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/000000000130_anolis.jpg" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/000000000130_anolis.jpg"
new file mode 100644
index 0000000000000000000000000000000000000000..25e606c9c5d28fccaf9f6caa351e3720570e4162
Binary files /dev/null and "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/000000000130_anolis.jpg" differ
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/T-One\346\246\202\350\277\260.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/T-One\346\246\202\350\277\260.md"
new file mode 100644
index 0000000000000000000000000000000000000000..74f3dbc4638e7e414a44eba81a927b219691bc3a
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/T-One\346\246\202\350\277\260.md"
@@ -0,0 +1,30 @@
+### T- One是什么
+ T-One是一站式的自动化质量协作平台；打通了测试计划、测试准备、测试执行、测试分析、测试报告、覆盖率检测、智能Bisect，环境服务等流程的闭环，为社区研发提供一站式质量服务。
+
+
+### 平台架构
+
+
+### 核心特点
+- 一站式质量平台：平台打通了测试准备、测试执行、测试分析、测试计划、测试报告、覆盖率检测、智能Bisect、智能巡检等流程全闭环，为社区研发提供一站式测试支撑。
+ - 支持多CPU混合架构（x86、arm、loogarch、risc-v）
+ - 支持多操作系统类型（龙蜥OS、centos、debian等）
+ - 支持复杂环境测试（企业内网、独立隔离、弹性云虚拟机/容器、应用集群及多种混合环境）
+
+- 质量协作能力：通过分布式的业务架构和独立租户空间能力，支持多企业、多团队的质量协作模式。
+- 数据分析能力：平台提供了时序分析、对比分析，以及聚合生成测试报告的能力，在大量测试之后对数据进行分析以发现软件问题。
+- 开源软件包CI服务：社区开发者可以将自己的软件包(可来自代码托管平台如github/gitee/codeup等)注册到Testfarm, 平台会监控软件包的代码变更，一旦有变更则会立即触发测试，并将测试结果通知开发者，方便开源软件包引入。
+- 开发者资源服务：社区开发者可以reserve测试环境并登陆，方便在测试环境中进行测试及debug。
+- 缺陷定位诊断服务：对于发现的软件缺陷，平台可以提供了缺陷的自动化定位诊断能力，可以发现引入缺陷的commit地址。
+
+
+### 应用场景
+- 场景1：OS发布测试，每次AnolisOS的发布，社区测试团队会根据发布测试策略进行大规模测试，保障产品发布质量，外部用户可以在Testfarm查看发布测试数据。
+- 场景2：开源软件包CI，社区开发者可以将软件包注册到平台，平台会自动监控软件包的变更，一旦发生变更会立即进行测试并推送测试结果。
+- 场景3：自定义测试，社区开发者根据自己的需求可以在T-One平台进行在线测试，或者使用命令行测试。
+- 场景4：离线测试，对于网络不可达的测试环境，用户可以使用离线测试模式测试并上传数据。
+- 场景5：独立部署，外部用户也可以在自己环境下独立部署平台，测试并上传数据到Testfarm。
+- 场景6：登陆测试环境，社区开发者可以根据需要reserve测试环境登陆进行测试及debug。
+- 场景7：缺陷定位诊断，一旦测试出缺陷，平台会自动诊断缺陷引入的commit。
+
+
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/assets/Dingtalk_20240614165831.jpg" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/assets/Dingtalk_20240614165831.jpg"
new file mode 100644
index 0000000000000000000000000000000000000000..925bf2945891170613821e8e7dbc9e4206d17c8d
Binary files /dev/null and "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/assets/Dingtalk_20240614165831.jpg" differ
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/assets/jiagou.jpeg" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/assets/jiagou.jpeg"
new file mode 100644
index 0000000000000000000000000000000000000000..392076fe21eafd908c238ff0e851862e84a05a2d
Binary files /dev/null and "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/assets/jiagou.jpeg" differ
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/atone\351\203\250\347\275\262.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/atone\351\203\250\347\275\262.md"
new file mode 100644
index 0000000000000000000000000000000000000000..12f85c9bb02d73ecf4fa31b8773d8b3743913cf7
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/atone\351\203\250\347\275\262.md"
@@ -0,0 +1,615 @@
+# 部署说明
+
+> 此文档以开源版本 T-One 最小单元部署举例说明，不保障系统的高可用及性能等
+>
+> 若期望大规模集群化部署可以联系SIG项目组进行具体讨论。
+> 若遇到问题请参照文未的 FAQ 文档，或进 SIG 群联系我们。
+
+**组件说明**： T-One 包含多个自研组件和几个开源组件，此文档以开源版本 T-One 最小单元部署举例说明。
+
+* 自研组件：tone-web、tone-agent-proxy、tone-agent、tone-runner等。
+* 开源组件：mysql、kafka、redis、zookeeper
+
+**机器要求**：
+
+* 硬件要求：推荐使用 8c16g 以上规格机器。
+* OS 要求：推荐使用 Anolis OS 系统进行部署（ 暂不支持debian、ubuntu等）。
+
+**部署说明**：
+- 主要分为安装环境、项目构建、项目启动、数据初始化等几个步骤。
+- 该文档以x86_64机器为例， 如果您的部署机器为其他arch类型的机器，则需要将docker-compose.yaml中指定的第三方开源组件镜像更换成对应的镜像源。
+- 可以自己指定安装目录，该文档以 ~/tone目录为例(推荐)。
+
+# 部署步骤
+> 后续步骤以 Anolis OS 8.6 环境为示例进行行详细说明。
+
+## 1. 环境准备
+
+### a. 安装docker
+```
+ yum -y install yum-utils
+ yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
+ yum install -y docker-ce # 若出错：yum install -y docker-ce --nobest --allowerasing
+
+ # 启动docker
+ systemctl enable docker
+ systemctl start docker
+ systemctl status docker
+```
+### b. 配置docker源
+```
+ vim /etc/docker/daemon.json
+ {
+ "registry-mirrors": [
+ "https://6kx4zyno.mirror.aliyuncs.com",
+ "https://docker.mirrors.ustc.edu.cn",
+ "http://hub-mirror.c.163.com",
+ "https://registry.docker-cn.com"]
+ }
+ systemctl restart docker
+ # 建议使用国内镜像源。 阿里云: https://6kx4zyno.mirror.aliyuncs.com，网易: http://hub-mirror.c.163.com
+```
+### c. 安装docker-compose
+```
+ pip3 install --upgrade pip
+ pip3 install docker-compose
+ docker-compose --version
+```
+
+## 2. 项目构建
+
+### a. 下载项目源码
+```shell
+yum install -y git
+
+git clone --single-branch --branch master https://gitee.com/anolis/tone-web.git ~/tone/code/tone-web
+git clone --single-branch --branch master https://gitee.com/anolis/tone-runner.git ~/tone/code/tone-runner
+git clone --single-branch --branch master https://gitee.com/anolis/tone-agent-proxy.git ~/tone/code/tone-agent-proxy
+git clone --single-branch --branch master https://gitee.com/anolis/tone-storage.git ~/tone/code/tone-storage
+```
+下载后的目录结构：
+```
+~/tone/code/
+ ├── tone-web
+ ├── tone-runner
+ ├── tone-agent-proxy
+ └── tone-storage
+```
+
+### b. 集成前端代码
+```shell
+# 下载前端代码包：
+wget https://anolis-service-pub.oss-cn-zhangjiakou.aliyuncs.com/biz-resource/tone/deploy/front/tone-front-latest.zip
+wget https://anolis-service-pub.oss-cn-zhangjiakou.aliyuncs.com/biz-resource/tone/deploy/front/toneagent-front-latest.zip
+# 安装unzip命令
+yum install -y unzip
+# 解压到指定目录
+unzip -j -o tone-front-latest.zip -d ~/tone/code/tone-web/static/front/
+unzip -j -o toneagent-front-latest.zip -d ~/tone/code/tone-agent-proxy/static/front/
+```
+
+## 3. 项目配置
+### a. 下载 docker-compose.yaml
+```shell
+cd ~/tone
+wget https://anolis-service-pub.oss-cn-zhangjiakou.aliyuncs.com/biz-resource/tone/deploy/docker-compose.yaml
+```
+
+### b. 设置并替换变量
+执行以下脚本(需手动替换`必填的`变量):
+```shell
+# 部署机外网IP地址(必填)
+server_ip=
+
+# 账号密码(必填)
+db_password=
+redis_password=
+tone_storage_password=
+
+# 镜像版本标签(非必改、默认latest)
+version_tag=latest
+
+# token(非必改、可自动生成)
+toneagent_access_key=$(uuidgen)
+toneagent_secret_key=$(uuidgen)
+admin_urls_token=$(uuidgen)
+pub_api_token=$(uuidgen)
+
+sed -i "s/var_db_password/${db_password}/g" docker-compose.yaml
+sed -i "s/var_redis_password/${redis_password}/g" docker-compose.yaml
+sed -i "s/var_tone_storage/${tone_storage_password}/g" docker-compose.yaml
+sed -i "s/var_toneagent_access_key/${toneagent_access_key}/g" docker-compose.yaml
+sed -i "s/var_toneagent_secret_key/${toneagent_secret_key}/g" docker-compose.yaml
+sed -i "s/var_admin_urls_token/${admin_urls_token}/g" docker-compose.yaml
+sed -i "s/var_pub_api_token/${pub_api_token}/g" docker-compose.yaml
+sed -i "s/var_version_tag/${version_tag}/g" docker-compose.yaml
+sed -i "s/var_server_ip/${server_ip}/g" docker-compose.yaml
+```
+
+### c. 启动docker-compose
+```shell
+docker-compose -f ~/tone/docker-compose.yaml up --build -d
+# 注：如代码有更新或首次部署，需要加 --build 参数才会自动重新打包镜像
+```
+
+## 4. 数据初始化
+### a.初始化db
+* 进入`mysql` docker 镜像中，`docker exec -it {数据库容器ID} bash`
+* 连接数据库：`mysql -h 127.0.0.1 -P 3306 -u root -p`
+* 创建 `T-One` 数据库 `tone-db`，`ToneAgent` 数据库 `toneagent-db`
+ ```
+ CREATE DATABASE `tone-db` CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
+ CREATE DATABASE `toneagent-db` CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
+ ```
+ 也可以直接通过 mysql 可视化界面初始化数据库
+
+### b.初始化 `T-One` 数据
+浏览器或者curl命令请求接口($admin_urls_token可在docker-compose配置里查看或更改)
+```shell
+curl -s "http://${server_ip}:8080/admin/migrate/?token=${admin_urls_token}"
+curl -s "http://${server_ip}:8080/admin/init_data/?token=${admin_urls_token}"
+curl -s "http://${server_ip}:8080/admin/create_superuser/?token=${admin_urls_token}&username=admin&password=admin123."
+curl -s "http://${server_ip}:8081/admin/migrate/?token=${admin_urls_token}"
+curl -s "http://${server_ip}:8081/admin/create_superuser/?token=${admin_urls_token}&username=admin&password=admin123."
+curl -s "http://${server_ip}:8081/admin/import_access_token/?token=${admin_urls_token}"
+```
+
+### c. `T-One` 关联依赖配置
+**系统执行任务还需对以下配置进行设置**
+
+- 配置 `T-One` 测试用例
+- 配置`T-One` 测试机器
+- 配置 `ToneAgent` `token`
+ - 在 ToneAgent 系统-账号管理中增加一组 token
+ - 更改 docker-compose 配置中的toneagent_access_key和toneagent_secret_key
+
+## 5. 验证
+使用浏览器打开链接查看： `T-One` 页面：`http://{host}:8080` `ToneAgent` 管理页面：`http://{host}:8081`
+
+## 6. T-One 多生态使用
+`T-One` + `TestLib`
+### a. 创建 `TestLib` 数据库
+- 进入 mysql docker 镜像，docker exec -it {数据库容器ID} bash
+- 连接数据库：mysql -h 127.0.0.1 -P 3306 -u root -p
+- 创建 TestLib 数据库 testlib
+
+ CREATE DATABASE \`test-lib\` CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
+- 创建 TestLib 数据库表
+### testlib数据库初始化
+
+ 点击展开/折叠脚本
+
+```shell
+
+/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
+/*!40101 SET NAMES utf8 */;
+/*!50503 SET NAMES utf8mb4 */;
+/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
+/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
+
+-- 表 test-lib.case 结构
+CREATE TABLE IF NOT EXISTS `case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试用例名称',
+ `creator` varchar(64) NOT NULL COMMENT '负责人',
+ `type` enum('FUNCTIONAL','PERFORMANCE','STRESS','LOAD','SECURITY','COMPATIBILITY','OTHERS') NOT NULL COMMENT '测试用例类型',
+ `priority` enum('PRIORITY_0','PRIORITY_1','PRIORITY_2','PRIORITY_3') NOT NULL COMMENT '测试用例的优先级',
+ `suite_name` varchar(128) DEFAULT NULL COMMENT '测试套名称',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试用例执行方式,手动、自动',
+ `run_model` enum('SINGLE','CLUSTER') NOT NULL COMMENT '测试用例运行模式,单机、集群',
+ `is_available` tinyint(1) NOT NULL COMMENT '测试用例是否可用',
+ `tone_case` varchar(128) DEFAULT NULL COMMENT 'T-One测试用例，当run_method为自动的时候生效',
+ `device_type` varchar(128) DEFAULT 'unlimit' COMMENT '设备类型,可多选,默认支持所有设备',
+ `device_arch` varchar(256) NOT NULL COMMENT '设备架构类型,可多选,默认支撑所有类型',
+ `labels` varchar(256) DEFAULT NULL COMMENT '设备标签,多个用,隔开',
+ `desc` varchar(512) DEFAULT NULL COMMENT '用例描述',
+ `pre_condition` varchar(512) DEFAULT NULL COMMENT '前置条件',
+ `steps` json DEFAULT NULL COMMENT '操作步骤',
+ `custom_fields` json DEFAULT NULL COMMENT '测试用例扩展属性',
+ `parent` int(11) NOT NULL COMMENT '测试用例分类节点',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`),
+ KEY `ix_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=31 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label 结构
+CREATE TABLE IF NOT EXISTS `case_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '用例标签',
+ `creator` varchar(64) NOT NULL COMMENT '标签创建人',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label_map 结构
+CREATE TABLE IF NOT EXISTS `case_label_map` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_name` varchar(64) NOT NULL COMMENT '用例名称',
+ `case_id` int(11) NOT NULL COMMENT '用例ID',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_label_map_label_name` (`label_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_tree 结构
+CREATE TABLE IF NOT EXISTS `case_tree` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(16) NOT NULL COMMENT '用例结构树节点名称',
+ `parent` int(11) NOT NULL COMMENT '父节点id',
+ `level` int(11) NOT NULL COMMENT '树结构的深度',
+ `path` varchar(128) NOT NULL COMMENT '模块完整路径',
+ `children_nums` int(11) NOT NULL COMMENT '子节点数量',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_tree_path` (`path`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device 结构
+CREATE TABLE IF NOT EXISTS `device` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备名称',
+ `arch` enum('X86','ARCH64','RISCV','LOONGARCH','NOARCH','OTHERS') NOT NULL COMMENT '设备架构',
+ `ip` varchar(16) NOT NULL COMMENT '设备ip',
+ `type` enum('UNLIMIT','VM','DOCKER','PHYSICS') NOT NULL COMMENT '设备类型',
+ `sn` varchar(16) DEFAULT NULL COMMENT '设备序号',
+ `status` tinyint(1) NOT NULL COMMENT '设备是否可用',
+ `label` json DEFAULT NULL COMMENT '设备标签列表数组',
+ `owner` varchar(256) NOT NULL COMMENT '设备负责人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label 结构
+CREATE TABLE IF NOT EXISTS `device_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备标签名称',
+ `color` varchar(32) NOT NULL COMMENT '设备标签颜色',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `ix_device_label_name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label_relationship 结构
+CREATE TABLE IF NOT EXISTS `device_label_relationship` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_id` int(11) NOT NULL COMMENT '机器Label id',
+ `device_id` int(11) NOT NULL COMMENT '机器Label id',
+ `is_delete` tinyint(1) DEFAULT NULL COMMENT '对应关系是否删除',
+ PRIMARY KEY (`id`),
+ KEY `ix_device_label_relationship_device_id` (`device_id`),
+ KEY `ix_device_label_relationship_label_id` (`label_id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.func_result 结构
+CREATE TABLE IF NOT EXISTS `func_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `sub_case_name` varchar(128) NOT NULL COMMENT 'tone job名称',
+ `sub_case_result` enum('SUCCESS','FAIL','SKIP') NOT NULL COMMENT '功能结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `current` json DEFAULT NULL,
+ `expect` json DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_func_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_func_result_task_id` (`task_id`),
+ KEY `ix_func_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_func_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=479 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.outline 结构
+CREATE TABLE IF NOT EXISTS `outline` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试大纲文件名',
+ `title` varchar(128) NOT NULL COMMENT '测试大纲的标题',
+ `owner` varchar(16) NOT NULL COMMENT '测试大纲负责人',
+ `tid` varchar(256) NOT NULL COMMENT 'oss文件地址',
+ `remark` varchar(64) DEFAULT NULL COMMENT '测试大纲备注描述信息',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.perf_result 结构
+CREATE TABLE IF NOT EXISTS `perf_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `metric` varchar(128) NOT NULL COMMENT '指标名称',
+ `test_value` varchar(64) DEFAULT NULL COMMENT '测试值',
+ `cv_value` varchar(64) DEFAULT NULL COMMENT 'cv值',
+ `max_value` varchar(64) DEFAULT NULL COMMENT '最大值',
+ `min_value` varchar(64) DEFAULT NULL COMMENT '最小值',
+ `unit` varchar(64) DEFAULT NULL COMMENT '测试单位',
+ `track_result` enum('NA','INVALID','NORMAL','DECLINE','INCREASE') NOT NULL COMMENT '跟踪结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ PRIMARY KEY (`id`),
+ KEY `ix_perf_result_task_id` (`task_id`),
+ KEY `ix_perf_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_perf_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_perf_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan 结构
+CREATE TABLE IF NOT EXISTS `plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(64) NOT NULL COMMENT '测试方案名称',
+ `req_id` int(11) DEFAULT NULL COMMENT '测试需求id',
+ `req_title` varchar(128) DEFAULT NULL COMMENT '测试需求标题',
+ `content` json DEFAULT NULL COMMENT '测试方案内容',
+ `status` varchar(16) NOT NULL COMMENT '测试方案阶段状态',
+ `cases` varchar(256) DEFAULT NULL COMMENT '测试用例,多个使用","隔开',
+ `tasks` varchar(256) DEFAULT NULL COMMENT '测试任务,多个使用","隔开',
+ `reviewers` varchar(256) NOT NULL COMMENT '方案评审人列表',
+ `owner` varchar(256) NOT NULL COMMENT '测试需求的负责人，多个以,隔开',
+ `report` tinyint(1) NOT NULL COMMENT '测试报告是否已生成',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `title` (`title`)
+) ENGINE=InnoDB AUTO_INCREMENT=63 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan_review 结构
+CREATE TABLE IF NOT EXISTS `plan_review` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `reviewer` varchar(32) NOT NULL COMMENT '测试需方案的评审人',
+ `status` varchar(16) NOT NULL COMMENT '评审状态',
+ `desc` varchar(512) DEFAULT NULL COMMENT '评审内容',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_category 结构
+CREATE TABLE IF NOT EXISTS `product_category` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '大类名称',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_plan 结构
+CREATE TABLE IF NOT EXISTS `product_plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `test_product_id` int(11) NOT NULL COMMENT '测试产品id',
+ `plan_id` int(11) NOT NULL COMMENT '测试产品实际复制执行的plan id',
+ `executor` varchar(256) NOT NULL COMMENT '测试产品执行人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.requirement 结构
+CREATE TABLE IF NOT EXISTS `requirement` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(128) NOT NULL COMMENT '测试需求标题',
+ `outline_id` int(11) DEFAULT NULL COMMENT '测试大纲id',
+ `outline_title` varchar(64) DEFAULT NULL COMMENT '测试大纲标题',
+ `content` json NOT NULL COMMENT '测试需求的描述内容',
+ `status` varchar(16) NOT NULL COMMENT '测试需求阶段',
+ `owner` varchar(16) NOT NULL COMMENT '测试需求的创建人',
+ `assignee` varchar(256) NOT NULL COMMENT '测试需求的指派人，多个以,隔开',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.task 结构
+CREATE TABLE IF NOT EXISTS `task` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '任务名称',
+ `status` varchar(16) NOT NULL COMMENT '任务执行状态',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试任务执行方式',
+ `owner` varchar(256) NOT NULL COMMENT '任务执行人',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `plan_title` varchar(256) NOT NULL COMMENT '测试方案标题',
+ `cases` varchar(256) NOT NULL COMMENT '测试用例,多个使用,隔开',
+ `desc` varchar(256) DEFAULT NULL COMMENT '备注',
+ `run_result` json DEFAULT NULL COMMENT '手动用例执行结果',
+ `config` json DEFAULT NULL COMMENT '测试任务配置',
+ `device_id` int(11) DEFAULT NULL COMMENT '测试设备ID',
+ `device_ip` varchar(256) DEFAULT NULL COMMENT '测试机器IP',
+ `workspace` varchar(128) NOT NULL COMMENT 'tone workspace',
+ `project` varchar(128) NOT NULL COMMENT 'tone project',
+ `job_type` varchar(128) NOT NULL COMMENT 'tone job type',
+ `test_type` varchar(32) DEFAULT 'others' COMMENT '测试任务类型',
+ `cluster` varchar(256) DEFAULT NULL COMMENT '测试机器集群名称',
+ `tags` varchar(256) DEFAULT NULL COMMENT '测试机器标签',
+ `tsn` varchar(256) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_task_plan_id` (`plan_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=90 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_product 结构
+CREATE TABLE IF NOT EXISTS `test_product` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试产品名称',
+ `category_id` int(11) NOT NULL COMMENT '大类id',
+ `origin_plan_id` int(11) NOT NULL COMMENT '测试产品对应的plan id',
+ `desc` varchar(256) DEFAULT NULL COMMENT '产品描述',
+ `test_method` varchar(256) DEFAULT NULL COMMENT '测试方法',
+ `test_requirement` varchar(256) DEFAULT NULL COMMENT '测试要求',
+ `need_config` tinyint(1) DEFAULT NULL COMMENT '是否扩展配置',
+ `owner` varchar(256) NOT NULL DEFAULT '' COMMENT '测试产品创建人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_suite 结构
+CREATE TABLE IF NOT EXISTS `test_suite` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(128) NOT NULL COMMENT '测试套名称',
+ `creator` varchar(64) NOT NULL COMMENT '测试套的创建人员',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_case 结构
+CREATE TABLE IF NOT EXISTS `tone_case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone用例ID',
+ `tone_case_name` varchar(256) NOT NULL COMMENT 'tone用例名称',
+ `suite_id` int(11) NOT NULL COMMENT 'suite ID',
+ `suite_name` varchar(256) NOT NULL COMMENT 'suite用例名称',
+ `test_type` varchar(64) DEFAULT NULL COMMENT '测试类型',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_case_tone_case_name` (`tone_case_name`),
+ KEY `ix_tone_case_suite_id` (`suite_id`),
+ KEY `ix_tone_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=603 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_job 结构
+CREATE TABLE IF NOT EXISTS `tone_job` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(100) NOT NULL COMMENT 'tone job名称',
+ `state` enum('PENDING','RUNNING','SUCCESS','FAIL','STOP','SKIP') NOT NULL COMMENT 'tone job状态',
+ `test_type` enum('FUNCTIONAL','PERFORMANCE') NOT NULL COMMENT '测试类型',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `tone_job_link` varchar(100) DEFAULT '' COMMENT 'tone job链接',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `server_info` json DEFAULT NULL COMMENT '存储tone job的机器信息',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_job_tone_job_id` (`tone_job_id`),
+ KEY `ix_tone_job_task_id` (`task_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=51 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_pull 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_pull` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=76149 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_push 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_push` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user 结构
+CREATE TABLE IF NOT EXISTS `user` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) DEFAULT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ KEY `ix_user_user_name` (`user_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_open_source 结构
+CREATE TABLE IF NOT EXISTS `user_open_source` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) NOT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `password` varchar(64) NOT NULL COMMENT '用户密码,前端对密码md5加密后的值',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ `token` varchar(256) NOT NULL COMMENT 'api访问凭证',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ UNIQUE KEY `email` (`email`),
+ KEY `ix_user_open_source_token` (`token`(255))
+) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_role_op_record 结构
+CREATE TABLE IF NOT EXISTS `user_role_op_record` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `applicant` varchar(64) NOT NULL COMMENT '申请人name',
+ `applicant_id` int(11) NOT NULL COMMENT '申请人ID',
+ `apply_reason` varchar(512) DEFAULT NULL COMMENT '申请理由',
+ `signer` varchar(64) DEFAULT NULL COMMENT '评审人name',
+ `has_review` tinyint(1) NOT NULL COMMENT '是否已经审核',
+ `review_result` enum('INIT','PASS','FAIL') NOT NULL COMMENT '审核结果',
+ `review_reason` varchar(512) DEFAULT NULL COMMENT '评审意见',
+ `method` enum('APPROVE','UPGRADE','DOWNGRADE','DELETE') NOT NULL COMMENT '操作方式',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;
+/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;
+/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
+
+
+```
+
+
+### b.TestLib 服务依赖
+### c. clone test-lib代码到~/tone/code目录下
+```shell
+git clone --single-branch --branch master https://gitee.com/anolis/testlib.git ~/tone/code/testlib
+```
+### d.增加docker-compose配置
+```yaml
+# docker-compose.yaml service下增加test-lib
+ test-lib:
+ build:
+ context: code/testlib/
+ dockerfile: Dockerfile
+ args:
+ APP_NAME: test-lib
+ ENV: daily
+ image: test-lib:latest
+ ports:
+ - "8005:8005"
+ depends_on:
+ - mysql
+ - redis
+ environment:
+ <<: *common-variables
+ # db
+ db_url: mysql+aiomysql://${db_user}:{db_password}@mysql:3306/test-lib
+ # redis
+ redis_url: redis://:${redis_password}@redis:6379/10
+ # app
+ tone_host: http://${server_ip}:8080/
+ tone_token: tone_token
+ tone_user_name: tone_user_name
+ main_domain: http://${server_ip}:8005
+ oss_url: http://${server_ip}:8005
+```
+#### e.重启服务
+```shell
+docker-compose -f ~/tone/docker-compose.yaml up --build -d
+```
+## 7. 独立部署 FAQ
+https://tone.openanolis.cn/help_doc/12
\ No newline at end of file
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/a\347\224\250\346\210\267\350\201\206\345\220\254-copy/test.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/a\347\224\250\346\210\267\350\201\206\345\220\254-copy/test.md"
new file mode 100644
index 0000000000000000000000000000000000000000..b09df7d02fee342106c45e78485a992609d67bdb
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/a\347\224\250\346\210\267\350\201\206\345\220\254-copy/test.md"
@@ -0,0 +1,70 @@
+# 一级标题
+## 二级标题
+### 三级标题
+**粗体文本**
+
+__cuti__
+
+*斜体文本*
+
+_xieti_
+
+下划线
+
+~~删除线~~
+
+上标：Xy
+
+下标：An
+
+> 引用文本
+- 无序列表项1
+ - 第二层
+- 无序列表项2
+* * *
+1. 有序列表项1
+2. 有序列表项2
+---
+[链接文本](https://gitee.com/suli01/community/edit/master/sig/T-One/content/%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97/%E7%94%A8%E6%88%B7%E8%81%86%E5%90%AC/test.md)
+
+链接名称
+
+'''python
+def hello_world():
+ print("Hello, world!")
+
+
+
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+
+- [x] ：已完成事项
+
+
+
+
+ 点击展开/折叠脚本
+
+```shell
+
+/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
+/*!40101 SET NAMES utf8 */;
+/*!50503 SET NAMES utf8mb4 */;
+/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
+/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
+
+-- 表 test-lib.case 结构
+CREATE TABLE IF NOT EXISTS `case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试用例名称',
+ `creator` varchar(64) NOT NULL COMMENT '负责人',
+ `type` enum('FUNCTIONAL','PERFORMANCE','STRESS','LOAD','SECURITY','COMPATIBILITY','OTHERS') NOT NULL COMMENT '测试用例类型',
+ `priority` enum('PRIORITY_0','PRIORITY_1','PRIORITY_2','PRIORITY_3') NOT NULL COMMENT '测试用例的优先级',
+ `suite_name` varchar(128) DEFAULT NULL COMMENT '测试套名称',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试用例执行方式,手动、自动',
+ `run_model` enum('SINGLE','CLUSTER') NOT NULL COMMENT '测试用例运行模式,单机、集群',
+ `is_available` tinyint(1) NOT NULL COMMENT '测试用例是否可用',
+ `tone_case` varchar(128) DEFAULT NULL COMMENT 'T-One测试用例，当run_method为自动的时候生效',
+ `device_type` varchar(128) DEFAULT 'unlimit' COMMENT '设备类型,可多选,默认支持所有设备',
+ `device_arch` varchar(256) NOT NULL COMMENT '设备架构类型,可多选,默认支撑所有类型',
+ `labels` varchar(256) DEFAULT NULL COMMENT '设备标签,多个用,隔开',
+ `desc` varchar(512) DEFAULT NULL COMMENT '用例描述',
+ `pre_condition` varchar(512) DEFAULT NULL COMMENT '前置条件',
+ `steps` json DEFAULT NULL COMMENT '操作步骤',
+ `custom_fields` json DEFAULT NULL COMMENT '测试用例扩展属性',
+ `parent` int(11) NOT NULL COMMENT '测试用例分类节点',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`),
+ KEY `ix_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=31 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label 结构
+CREATE TABLE IF NOT EXISTS `case_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '用例标签',
+ `creator` varchar(64) NOT NULL COMMENT '标签创建人',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label_map 结构
+CREATE TABLE IF NOT EXISTS `case_label_map` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_name` varchar(64) NOT NULL COMMENT '用例名称',
+ `case_id` int(11) NOT NULL COMMENT '用例ID',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_label_map_label_name` (`label_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_tree 结构
+CREATE TABLE IF NOT EXISTS `case_tree` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(16) NOT NULL COMMENT '用例结构树节点名称',
+ `parent` int(11) NOT NULL COMMENT '父节点id',
+ `level` int(11) NOT NULL COMMENT '树结构的深度',
+ `path` varchar(128) NOT NULL COMMENT '模块完整路径',
+ `children_nums` int(11) NOT NULL COMMENT '子节点数量',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_tree_path` (`path`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device 结构
+CREATE TABLE IF NOT EXISTS `device` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备名称',
+ `arch` enum('X86','ARCH64','RISCV','LOONGARCH','NOARCH','OTHERS') NOT NULL COMMENT '设备架构',
+ `ip` varchar(16) NOT NULL COMMENT '设备ip',
+ `type` enum('UNLIMIT','VM','DOCKER','PHYSICS') NOT NULL COMMENT '设备类型',
+ `sn` varchar(16) DEFAULT NULL COMMENT '设备序号',
+ `status` tinyint(1) NOT NULL COMMENT '设备是否可用',
+ `label` json DEFAULT NULL COMMENT '设备标签列表数组',
+ `owner` varchar(256) NOT NULL COMMENT '设备负责人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label 结构
+CREATE TABLE IF NOT EXISTS `device_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备标签名称',
+ `color` varchar(32) NOT NULL COMMENT '设备标签颜色',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `ix_device_label_name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label_relationship 结构
+CREATE TABLE IF NOT EXISTS `device_label_relationship` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_id` int(11) NOT NULL COMMENT '机器Label id',
+ `device_id` int(11) NOT NULL COMMENT '机器Label id',
+ `is_delete` tinyint(1) DEFAULT NULL COMMENT '对应关系是否删除',
+ PRIMARY KEY (`id`),
+ KEY `ix_device_label_relationship_device_id` (`device_id`),
+ KEY `ix_device_label_relationship_label_id` (`label_id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.func_result 结构
+CREATE TABLE IF NOT EXISTS `func_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `sub_case_name` varchar(128) NOT NULL COMMENT 'tone job名称',
+ `sub_case_result` enum('SUCCESS','FAIL','SKIP') NOT NULL COMMENT '功能结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `current` json DEFAULT NULL,
+ `expect` json DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_func_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_func_result_task_id` (`task_id`),
+ KEY `ix_func_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_func_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=479 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.outline 结构
+CREATE TABLE IF NOT EXISTS `outline` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试大纲文件名',
+ `title` varchar(128) NOT NULL COMMENT '测试大纲的标题',
+ `owner` varchar(16) NOT NULL COMMENT '测试大纲负责人',
+ `tid` varchar(256) NOT NULL COMMENT 'oss文件地址',
+ `remark` varchar(64) DEFAULT NULL COMMENT '测试大纲备注描述信息',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.perf_result 结构
+CREATE TABLE IF NOT EXISTS `perf_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `metric` varchar(128) NOT NULL COMMENT '指标名称',
+ `test_value` varchar(64) DEFAULT NULL COMMENT '测试值',
+ `cv_value` varchar(64) DEFAULT NULL COMMENT 'cv值',
+ `max_value` varchar(64) DEFAULT NULL COMMENT '最大值',
+ `min_value` varchar(64) DEFAULT NULL COMMENT '最小值',
+ `unit` varchar(64) DEFAULT NULL COMMENT '测试单位',
+ `track_result` enum('NA','INVALID','NORMAL','DECLINE','INCREASE') NOT NULL COMMENT '跟踪结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ PRIMARY KEY (`id`),
+ KEY `ix_perf_result_task_id` (`task_id`),
+ KEY `ix_perf_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_perf_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_perf_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan 结构
+CREATE TABLE IF NOT EXISTS `plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(64) NOT NULL COMMENT '测试方案名称',
+ `req_id` int(11) DEFAULT NULL COMMENT '测试需求id',
+ `req_title` varchar(128) DEFAULT NULL COMMENT '测试需求标题',
+ `content` json DEFAULT NULL COMMENT '测试方案内容',
+ `status` varchar(16) NOT NULL COMMENT '测试方案阶段状态',
+ `cases` varchar(256) DEFAULT NULL COMMENT '测试用例,多个使用","隔开',
+ `tasks` varchar(256) DEFAULT NULL COMMENT '测试任务,多个使用","隔开',
+ `reviewers` varchar(256) NOT NULL COMMENT '方案评审人列表',
+ `owner` varchar(256) NOT NULL COMMENT '测试需求的负责人，多个以,隔开',
+ `report` tinyint(1) NOT NULL COMMENT '测试报告是否已生成',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `title` (`title`)
+) ENGINE=InnoDB AUTO_INCREMENT=63 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan_review 结构
+CREATE TABLE IF NOT EXISTS `plan_review` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `reviewer` varchar(32) NOT NULL COMMENT '测试需方案的评审人',
+ `status` varchar(16) NOT NULL COMMENT '评审状态',
+ `desc` varchar(512) DEFAULT NULL COMMENT '评审内容',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_category 结构
+CREATE TABLE IF NOT EXISTS `product_category` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '大类名称',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_plan 结构
+CREATE TABLE IF NOT EXISTS `product_plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `test_product_id` int(11) NOT NULL COMMENT '测试产品id',
+ `plan_id` int(11) NOT NULL COMMENT '测试产品实际复制执行的plan id',
+ `executor` varchar(256) NOT NULL COMMENT '测试产品执行人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.requirement 结构
+CREATE TABLE IF NOT EXISTS `requirement` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(128) NOT NULL COMMENT '测试需求标题',
+ `outline_id` int(11) DEFAULT NULL COMMENT '测试大纲id',
+ `outline_title` varchar(64) DEFAULT NULL COMMENT '测试大纲标题',
+ `content` json NOT NULL COMMENT '测试需求的描述内容',
+ `status` varchar(16) NOT NULL COMMENT '测试需求阶段',
+ `owner` varchar(16) NOT NULL COMMENT '测试需求的创建人',
+ `assignee` varchar(256) NOT NULL COMMENT '测试需求的指派人，多个以,隔开',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.task 结构
+CREATE TABLE IF NOT EXISTS `task` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '任务名称',
+ `status` varchar(16) NOT NULL COMMENT '任务执行状态',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试任务执行方式',
+ `owner` varchar(256) NOT NULL COMMENT '任务执行人',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `plan_title` varchar(256) NOT NULL COMMENT '测试方案标题',
+ `cases` varchar(256) NOT NULL COMMENT '测试用例,多个使用,隔开',
+ `desc` varchar(256) DEFAULT NULL COMMENT '备注',
+ `run_result` json DEFAULT NULL COMMENT '手动用例执行结果',
+ `config` json DEFAULT NULL COMMENT '测试任务配置',
+ `device_id` int(11) DEFAULT NULL COMMENT '测试设备ID',
+ `device_ip` varchar(256) DEFAULT NULL COMMENT '测试机器IP',
+ `workspace` varchar(128) NOT NULL COMMENT 'tone workspace',
+ `project` varchar(128) NOT NULL COMMENT 'tone project',
+ `job_type` varchar(128) NOT NULL COMMENT 'tone job type',
+ `test_type` varchar(32) DEFAULT 'others' COMMENT '测试任务类型',
+ `cluster` varchar(256) DEFAULT NULL COMMENT '测试机器集群名称',
+ `tags` varchar(256) DEFAULT NULL COMMENT '测试机器标签',
+ `tsn` varchar(256) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_task_plan_id` (`plan_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=90 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_product 结构
+CREATE TABLE IF NOT EXISTS `test_product` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试产品名称',
+ `category_id` int(11) NOT NULL COMMENT '大类id',
+ `origin_plan_id` int(11) NOT NULL COMMENT '测试产品对应的plan id',
+ `desc` varchar(256) DEFAULT NULL COMMENT '产品描述',
+ `test_method` varchar(256) DEFAULT NULL COMMENT '测试方法',
+ `test_requirement` varchar(256) DEFAULT NULL COMMENT '测试要求',
+ `need_config` tinyint(1) DEFAULT NULL COMMENT '是否扩展配置',
+ `owner` varchar(256) NOT NULL DEFAULT '' COMMENT '测试产品创建人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_suite 结构
+CREATE TABLE IF NOT EXISTS `test_suite` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(128) NOT NULL COMMENT '测试套名称',
+ `creator` varchar(64) NOT NULL COMMENT '测试套的创建人员',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_case 结构
+CREATE TABLE IF NOT EXISTS `tone_case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone用例ID',
+ `tone_case_name` varchar(256) NOT NULL COMMENT 'tone用例名称',
+ `suite_id` int(11) NOT NULL COMMENT 'suite ID',
+ `suite_name` varchar(256) NOT NULL COMMENT 'suite用例名称',
+ `test_type` varchar(64) DEFAULT NULL COMMENT '测试类型',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_case_tone_case_name` (`tone_case_name`),
+ KEY `ix_tone_case_suite_id` (`suite_id`),
+ KEY `ix_tone_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=603 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_job 结构
+CREATE TABLE IF NOT EXISTS `tone_job` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(100) NOT NULL COMMENT 'tone job名称',
+ `state` enum('PENDING','RUNNING','SUCCESS','FAIL','STOP','SKIP') NOT NULL COMMENT 'tone job状态',
+ `test_type` enum('FUNCTIONAL','PERFORMANCE') NOT NULL COMMENT '测试类型',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `tone_job_link` varchar(100) DEFAULT '' COMMENT 'tone job链接',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `server_info` json DEFAULT NULL COMMENT '存储tone job的机器信息',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_job_tone_job_id` (`tone_job_id`),
+ KEY `ix_tone_job_task_id` (`task_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=51 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_pull 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_pull` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=76149 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_push 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_push` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user 结构
+CREATE TABLE IF NOT EXISTS `user` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) DEFAULT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ KEY `ix_user_user_name` (`user_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_open_source 结构
+CREATE TABLE IF NOT EXISTS `user_open_source` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) NOT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `password` varchar(64) NOT NULL COMMENT '用户密码,前端对密码md5加密后的值',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ `token` varchar(256) NOT NULL COMMENT 'api访问凭证',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ UNIQUE KEY `email` (`email`),
+ KEY `ix_user_open_source_token` (`token`(255))
+) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_role_op_record 结构
+CREATE TABLE IF NOT EXISTS `user_role_op_record` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `applicant` varchar(64) NOT NULL COMMENT '申请人name',
+ `applicant_id` int(11) NOT NULL COMMENT '申请人ID',
+ `apply_reason` varchar(512) DEFAULT NULL COMMENT '申请理由',
+ `signer` varchar(64) DEFAULT NULL COMMENT '评审人name',
+ `has_review` tinyint(1) NOT NULL COMMENT '是否已经审核',
+ `review_result` enum('INIT','PASS','FAIL') NOT NULL COMMENT '审核结果',
+ `review_reason` varchar(512) DEFAULT NULL COMMENT '评审意见',
+ `method` enum('APPROVE','UPGRADE','DOWNGRADE','DELETE') NOT NULL COMMENT '操作方式',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;
+/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;
+/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
+
+
+```
+
+
+### b.TestLib 服务依赖
+### c. clone test-lib代码到~/tone/code目录下
+```shell
+git clone --single-branch --branch master https://gitee.com/anolis/testlib.git ~/tone/code/testlib
+```
+### d.增加docker-compose配置
+```yaml
+# docker-compose.yaml service下增加test-lib
+ test-lib:
+ build:
+ context: code/testlib/
+ dockerfile: Dockerfile
+ args:
+ APP_NAME: test-lib
+ ENV: daily
+ image: test-lib:latest
+ ports:
+ - "8005:8005"
+ depends_on:
+ - mysql
+ - redis
+ environment:
+ <<: *common-variables
+ # db
+ db_url: mysql+aiomysql://${db_user}:{db_password}@mysql:3306/test-lib
+ # redis
+ redis_url: redis://:${redis_password}@redis:6379/10
+ # app
+ tone_host: http://${server_ip}:8080/
+ tone_token: tone_token
+ tone_user_name: tone_user_name
+ main_domain: http://${server_ip}:8005
+ oss_url: http://${server_ip}:8005
+```
+#### e.重启服务
+```shell
+docker-compose -f ~/tone/docker-compose.yaml up --build -d
+```
+## 7. 独立部署 FAQ
+https://tone.openanolis.cn/help_doc/12
\ No newline at end of file
diff --git "a/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/\347\224\250\346\210\267\350\201\206\345\220\254/test.md" "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/\347\224\250\346\210\267\350\201\206\345\220\254/test.md"
new file mode 100644
index 0000000000000000000000000000000000000000..b09df7d02fee342106c45e78485a992609d67bdb
--- /dev/null
+++ "b/sig/Anolis\350\277\201\347\247\273SIG/content/\347\224\250\346\210\267\346\214\207\345\215\2272/\347\224\250\346\210\267\350\201\206\345\220\254/test.md"
@@ -0,0 +1,70 @@
+# 一级标题
+## 二级标题
+### 三级标题
+**粗体文本**
+
+__cuti__
+
+*斜体文本*
+
+_xieti_
+
+下划线
+
+~~删除线~~
+
+上标：Xy
+
+下标：An
+
+> 引用文本
+- 无序列表项1
+ - 第二层
+- 无序列表项2
+* * *
+1. 有序列表项1
+2. 有序列表项2
+---
+[链接文本](https://gitee.com/suli01/community/edit/master/sig/T-One/content/%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97/%E7%94%A8%E6%88%B7%E8%81%86%E5%90%AC/test.md)
+
+链接名称
+
+'''python
+def hello_world():
+ print("Hello, world!")
+
+
+
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+
+- [x] ：已完成事项
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+- [x] ：已完成事项
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+- [ ] ：待完成事项
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+- [ ] ：待完成事项2
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+- [x] ：已完成事项
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+- [ ] ：待完成事项
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+- [ ] ：待完成事项2
+ | 列1 | 列2 | 列3 |
+ | --- | --- | --- |
+ | 单元格1 | 单元格2 | 单元格3 |
+ | 单元格4 | 单元格5 | 单元格6 |
+
+- [x] ：已完成事项
+
+
+
+
+
+网迅网卡已经按此流程合入 ANCK ：
+- 支持ANCK-5.10 10GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/540
+- 支持ANCK-4.19 10GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/709
+- 支持ANCK-4.19 1GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/1043
+- 支持ANCK-5.10 1GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/1063
+
+# 重要议题
+- 讨论并决策了将 ANCK-5.10 作为 Anolis8 的默认产品化内核，详情请点击[这里](https://gitee.com/anolis/community/blob/master/proposals/Anolis8%E4%B8%8AANCK-5.10%E4%BA%A7%E5%93%81%E5%8C%96%E7%9A%84%E6%8F%90%E8%AE%AE.md)。
+- 讨论并决策了将 ANCK-5.10 作为 Anolis23 的当前默认内核，详情请点击[这里](https://gitee.com/anolis/community/blob/master/proposals/anck-5.10%E4%BD%9C%E4%B8%BAanolis23%E7%9A%84%E5%86%85%E6%A0%B8%E9%80%89%E5%9E%8B%E7%9A%84%E6%8F%90%E8%AE%AE.md)。
+
+# 运营活动
+- [浪潮信息正式发布基于龙蜥 Anolis OS 的服务器操作系统 Inspur KOS](https://openanolis.cn/news/726244284765327879)。
+- 于2022.12.24 举办了“[龙蜥走进系列活动之走进浪潮信息 MeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4MTMyMTUwMQ==&mid=2247510368&idx=1&sn=95a1d511b32670f8388745682483046a&chksm=cf655a12f812d30494be938d7bf8a46b7244711c8fb75f44e8379ab261b1fd4aeb1c8bb0805e&scene=21#wechat_redirect)"，并成立了浪潮信息龙蜥联合实验室，致力于共建龙蜥社区的软硬件兼容性生态、标准建设和技术创新等。
diff --git "a/sig/T-One-copy2/content/\346\234\210\346\212\245/202301.md" "b/sig/T-One-copy2/content/\346\234\210\346\212\245/202301.md"
new file mode 100644
index 0000000000000000000000000000000000000000..85bbb428461066b1774f93d5ede99390bf2bc702
--- /dev/null
+++ "b/sig/T-One-copy2/content/\346\234\210\346\212\245/202301.md"
@@ -0,0 +1,101 @@
+# 整体进展
+
+- 发布 ANCK 5.10-013 版本。
+- 确定KABI机制整体方案。
+- 浪潮信息龙蜥联合实验室的工作事项更新。
+
+# ANCK 5.10-013 版本
+
+## 内核更新
+
+- 版本更新至 5.10.134-13
+- 重要内核缺陷及安全漏洞(CVE)修复
+- 支持用户态/dev/ioasid
+- SWIOTLB机制性能优化
+- virtio-net 打开 napi.tx 优化 TCP Small Queue 性能
+- 支持AST2600 PCIe 2D VGA Driver
+- 支持FT2500处理器
+- 支持动态开启Group identity特性
+- arm64平台默认内核启动cmdline调整
+- 添加 Compact Numa Aware (CNA) spinlock 功能支持
+- 丰富arm64的perf mem和perf c2c功能
+- fsck.xfs 支持日志恢复
+- hugetext自适应按需大页
+- 支持SGX动态内存管理
+- 使能wireguard模块
+
+## CVE修复列表
+
+详情请参考：
+
+- [Anolis OS 7](https://anas.openanolis.cn/errata/detail/ANSA-2023:0002)
+- [Anolis OS 8](https://anas.openanolis.cn/errata/detail/ANSA-2023:0001)
+
+重要CVE列表:
+
+- CVE-2021-4037
+- CVE-2022-0171
+- CVE-2022-1679
+- CVE-2022-2585
+- CVE-2022-2586
+- CVE-2022-2588
+- CVE-2022-2602
+- CVE-2022-26373
+- CVE-2022-2663
+- CVE-2022-2905
+- CVE-2022-2978
+- CVE-2022-3028
+- CVE-2022-3061
+- CVE-2022-3169
+- CVE-2022-3176
+- CVE-2022-3435
+- CVE-2022-3521
+- CVE-2022-3524
+- CVE-2022-3534
+- CVE-2022-3535
+- CVE-2022-3542
+- CVE-2022-3545
+- CVE-2022-3564
+- CVE-2022-3565
+- CVE-2022-3566
+- CVE-2022-3567
+- CVE-2022-3586
+- CVE-2022-3594
+- CVE-2022-3621
+- CVE-2022-3623
+- CVE-2022-3625
+- CVE-2022-3628
+- CVE-2022-3629
+- CVE-2022-3633
+- CVE-2022-3635
+- CVE-2022-3646
+- CVE-2022-3649
+- CVE-2022-36946
+- CVE-2022-39189
+- CVE-2022-39190
+- CVE-2022-39842
+- CVE-2022-40307
+- CVE-2022-40768
+- CVE-2022-41222
+- CVE-2022-41674
+- CVE-2022-42719
+- CVE-2022-42720
+- CVE-2022-42721
+- CVE-2022-42722
+- CVE-2022-42895
+- CVE-2022-42896
+- CVE-2022-43750
+- CVE-2022-4378
+
+# 龙蜥社区第三方驱动
+
+* 提供主流GPU在AnolisOS的Driver、CUDA、cuDNN安装测试与卸载指导文档：https://openanolis.cn/sig/AI_SIG/doc/721423765456666646
+
+# 重要议题
+
+- 调研并讨论了KABI机制的整体方案与实现细节。
+- 基于浪潮信息龙蜥联合实验室，讨论了关于整机硬件兼容性的相关事项，后续长期共建 AnolisOS 硬件兼容性标准和生态。
+
+# 运营活动
+
+- 无
diff --git "a/sig/T-One-copy2/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md" "b/sig/T-One-copy2/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md"
new file mode 100644
index 0000000000000000000000000000000000000000..30020428d41c0b35e0eb225c6a3b4a4a06f385a6
--- /dev/null
+++ "b/sig/T-One-copy2/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md"
@@ -0,0 +1,7 @@
+- 每月的月初总结发出上月的报告，并更新到 SIG 页面，如 2022.12
+
+- 月报包含内容：
+ + 整体进展：SIG 该月的亮点特性汇总。
+ + 具体进展：SIG 该月项目的详细进展，分别展开细节。
+ + 重要议题: SIG 该月讨论的重要议题。
+ + 运营活动: SIG 该月发生的运营活动。
diff --git "a/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/000000000130_anolis.jpg" "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/000000000130_anolis.jpg"
new file mode 100644
index 0000000000000000000000000000000000000000..25e606c9c5d28fccaf9f6caa351e3720570e4162
Binary files /dev/null and "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/000000000130_anolis.jpg" differ
diff --git "a/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/T-One\346\246\202\350\277\260.md" "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/T-One\346\246\202\350\277\260.md"
new file mode 100644
index 0000000000000000000000000000000000000000..74f3dbc4638e7e414a44eba81a927b219691bc3a
--- /dev/null
+++ "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/T-One\346\246\202\350\277\260.md"
@@ -0,0 +1,30 @@
+### T- One是什么
+ T-One是一站式的自动化质量协作平台；打通了测试计划、测试准备、测试执行、测试分析、测试报告、覆盖率检测、智能Bisect，环境服务等流程的闭环，为社区研发提供一站式质量服务。
+
+
+### 平台架构
+
+
+### 核心特点
+- 一站式质量平台：平台打通了测试准备、测试执行、测试分析、测试计划、测试报告、覆盖率检测、智能Bisect、智能巡检等流程全闭环，为社区研发提供一站式测试支撑。
+ - 支持多CPU混合架构（x86、arm、loogarch、risc-v）
+ - 支持多操作系统类型（龙蜥OS、centos、debian等）
+ - 支持复杂环境测试（企业内网、独立隔离、弹性云虚拟机/容器、应用集群及多种混合环境）
+
+- 质量协作能力：通过分布式的业务架构和独立租户空间能力，支持多企业、多团队的质量协作模式。
+- 数据分析能力：平台提供了时序分析、对比分析，以及聚合生成测试报告的能力，在大量测试之后对数据进行分析以发现软件问题。
+- 开源软件包CI服务：社区开发者可以将自己的软件包(可来自代码托管平台如github/gitee/codeup等)注册到Testfarm, 平台会监控软件包的代码变更，一旦有变更则会立即触发测试，并将测试结果通知开发者，方便开源软件包引入。
+- 开发者资源服务：社区开发者可以reserve测试环境并登陆，方便在测试环境中进行测试及debug。
+- 缺陷定位诊断服务：对于发现的软件缺陷，平台可以提供了缺陷的自动化定位诊断能力，可以发现引入缺陷的commit地址。
+
+
+### 应用场景
+- 场景1：OS发布测试，每次AnolisOS的发布，社区测试团队会根据发布测试策略进行大规模测试，保障产品发布质量，外部用户可以在Testfarm查看发布测试数据。
+- 场景2：开源软件包CI，社区开发者可以将软件包注册到平台，平台会自动监控软件包的变更，一旦发生变更会立即进行测试并推送测试结果。
+- 场景3：自定义测试，社区开发者根据自己的需求可以在T-One平台进行在线测试，或者使用命令行测试。
+- 场景4：离线测试，对于网络不可达的测试环境，用户可以使用离线测试模式测试并上传数据。
+- 场景5：独立部署，外部用户也可以在自己环境下独立部署平台，测试并上传数据到Testfarm。
+- 场景6：登陆测试环境，社区开发者可以根据需要reserve测试环境登陆进行测试及debug。
+- 场景7：缺陷定位诊断，一旦测试出缺陷，平台会自动诊断缺陷引入的commit。
+
+
diff --git "a/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/Dingtalk_20240614165831.jpg" "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/Dingtalk_20240614165831.jpg"
new file mode 100644
index 0000000000000000000000000000000000000000..925bf2945891170613821e8e7dbc9e4206d17c8d
Binary files /dev/null and "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/Dingtalk_20240614165831.jpg" differ
diff --git "a/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/jiagou.jpeg" "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/jiagou.jpeg"
new file mode 100644
index 0000000000000000000000000000000000000000..392076fe21eafd908c238ff0e851862e84a05a2d
Binary files /dev/null and "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/jiagou.jpeg" differ
diff --git "a/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/atone\351\203\250\347\275\262.md" "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/atone\351\203\250\347\275\262.md"
new file mode 100644
index 0000000000000000000000000000000000000000..12f85c9bb02d73ecf4fa31b8773d8b3743913cf7
--- /dev/null
+++ "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/atone\351\203\250\347\275\262.md"
@@ -0,0 +1,615 @@
+# 部署说明
+
+> 此文档以开源版本 T-One 最小单元部署举例说明，不保障系统的高可用及性能等
+>
+> 若期望大规模集群化部署可以联系SIG项目组进行具体讨论。
+> 若遇到问题请参照文未的 FAQ 文档，或进 SIG 群联系我们。
+
+**组件说明**： T-One 包含多个自研组件和几个开源组件，此文档以开源版本 T-One 最小单元部署举例说明。
+
+* 自研组件：tone-web、tone-agent-proxy、tone-agent、tone-runner等。
+* 开源组件：mysql、kafka、redis、zookeeper
+
+**机器要求**：
+
+* 硬件要求：推荐使用 8c16g 以上规格机器。
+* OS 要求：推荐使用 Anolis OS 系统进行部署（ 暂不支持debian、ubuntu等）。
+
+**部署说明**：
+- 主要分为安装环境、项目构建、项目启动、数据初始化等几个步骤。
+- 该文档以x86_64机器为例， 如果您的部署机器为其他arch类型的机器，则需要将docker-compose.yaml中指定的第三方开源组件镜像更换成对应的镜像源。
+- 可以自己指定安装目录，该文档以 ~/tone目录为例(推荐)。
+
+# 部署步骤
+> 后续步骤以 Anolis OS 8.6 环境为示例进行行详细说明。
+
+## 1. 环境准备
+
+### a. 安装docker
+```
+ yum -y install yum-utils
+ yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
+ yum install -y docker-ce # 若出错：yum install -y docker-ce --nobest --allowerasing
+
+ # 启动docker
+ systemctl enable docker
+ systemctl start docker
+ systemctl status docker
+```
+### b. 配置docker源
+```
+ vim /etc/docker/daemon.json
+ {
+ "registry-mirrors": [
+ "https://6kx4zyno.mirror.aliyuncs.com",
+ "https://docker.mirrors.ustc.edu.cn",
+ "http://hub-mirror.c.163.com",
+ "https://registry.docker-cn.com"]
+ }
+ systemctl restart docker
+ # 建议使用国内镜像源。 阿里云: https://6kx4zyno.mirror.aliyuncs.com，网易: http://hub-mirror.c.163.com
+```
+### c. 安装docker-compose
+```
+ pip3 install --upgrade pip
+ pip3 install docker-compose
+ docker-compose --version
+```
+
+## 2. 项目构建
+
+### a. 下载项目源码
+```shell
+yum install -y git
+
+git clone --single-branch --branch master https://gitee.com/anolis/tone-web.git ~/tone/code/tone-web
+git clone --single-branch --branch master https://gitee.com/anolis/tone-runner.git ~/tone/code/tone-runner
+git clone --single-branch --branch master https://gitee.com/anolis/tone-agent-proxy.git ~/tone/code/tone-agent-proxy
+git clone --single-branch --branch master https://gitee.com/anolis/tone-storage.git ~/tone/code/tone-storage
+```
+下载后的目录结构：
+```
+~/tone/code/
+ ├── tone-web
+ ├── tone-runner
+ ├── tone-agent-proxy
+ └── tone-storage
+```
+
+### b. 集成前端代码
+```shell
+# 下载前端代码包：
+wget https://anolis-service-pub.oss-cn-zhangjiakou.aliyuncs.com/biz-resource/tone/deploy/front/tone-front-latest.zip
+wget https://anolis-service-pub.oss-cn-zhangjiakou.aliyuncs.com/biz-resource/tone/deploy/front/toneagent-front-latest.zip
+# 安装unzip命令
+yum install -y unzip
+# 解压到指定目录
+unzip -j -o tone-front-latest.zip -d ~/tone/code/tone-web/static/front/
+unzip -j -o toneagent-front-latest.zip -d ~/tone/code/tone-agent-proxy/static/front/
+```
+
+## 3. 项目配置
+### a. 下载 docker-compose.yaml
+```shell
+cd ~/tone
+wget https://anolis-service-pub.oss-cn-zhangjiakou.aliyuncs.com/biz-resource/tone/deploy/docker-compose.yaml
+```
+
+### b. 设置并替换变量
+执行以下脚本(需手动替换`必填的`变量):
+```shell
+# 部署机外网IP地址(必填)
+server_ip=
+
+# 账号密码(必填)
+db_password=
+redis_password=
+tone_storage_password=
+
+# 镜像版本标签(非必改、默认latest)
+version_tag=latest
+
+# token(非必改、可自动生成)
+toneagent_access_key=$(uuidgen)
+toneagent_secret_key=$(uuidgen)
+admin_urls_token=$(uuidgen)
+pub_api_token=$(uuidgen)
+
+sed -i "s/var_db_password/${db_password}/g" docker-compose.yaml
+sed -i "s/var_redis_password/${redis_password}/g" docker-compose.yaml
+sed -i "s/var_tone_storage/${tone_storage_password}/g" docker-compose.yaml
+sed -i "s/var_toneagent_access_key/${toneagent_access_key}/g" docker-compose.yaml
+sed -i "s/var_toneagent_secret_key/${toneagent_secret_key}/g" docker-compose.yaml
+sed -i "s/var_admin_urls_token/${admin_urls_token}/g" docker-compose.yaml
+sed -i "s/var_pub_api_token/${pub_api_token}/g" docker-compose.yaml
+sed -i "s/var_version_tag/${version_tag}/g" docker-compose.yaml
+sed -i "s/var_server_ip/${server_ip}/g" docker-compose.yaml
+```
+
+### c. 启动docker-compose
+```shell
+docker-compose -f ~/tone/docker-compose.yaml up --build -d
+# 注：如代码有更新或首次部署，需要加 --build 参数才会自动重新打包镜像
+```
+
+## 4. 数据初始化
+### a.初始化db
+* 进入`mysql` docker 镜像中，`docker exec -it {数据库容器ID} bash`
+* 连接数据库：`mysql -h 127.0.0.1 -P 3306 -u root -p`
+* 创建 `T-One` 数据库 `tone-db`，`ToneAgent` 数据库 `toneagent-db`
+ ```
+ CREATE DATABASE `tone-db` CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
+ CREATE DATABASE `toneagent-db` CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
+ ```
+ 也可以直接通过 mysql 可视化界面初始化数据库
+
+### b.初始化 `T-One` 数据
+浏览器或者curl命令请求接口($admin_urls_token可在docker-compose配置里查看或更改)
+```shell
+curl -s "http://${server_ip}:8080/admin/migrate/?token=${admin_urls_token}"
+curl -s "http://${server_ip}:8080/admin/init_data/?token=${admin_urls_token}"
+curl -s "http://${server_ip}:8080/admin/create_superuser/?token=${admin_urls_token}&username=admin&password=admin123."
+curl -s "http://${server_ip}:8081/admin/migrate/?token=${admin_urls_token}"
+curl -s "http://${server_ip}:8081/admin/create_superuser/?token=${admin_urls_token}&username=admin&password=admin123."
+curl -s "http://${server_ip}:8081/admin/import_access_token/?token=${admin_urls_token}"
+```
+
+### c. `T-One` 关联依赖配置
+**系统执行任务还需对以下配置进行设置**
+
+- 配置 `T-One` 测试用例
+- 配置`T-One` 测试机器
+- 配置 `ToneAgent` `token`
+ - 在 ToneAgent 系统-账号管理中增加一组 token
+ - 更改 docker-compose 配置中的toneagent_access_key和toneagent_secret_key
+
+## 5. 验证
+使用浏览器打开链接查看： `T-One` 页面：`http://{host}:8080` `ToneAgent` 管理页面：`http://{host}:8081`
+
+## 6. T-One 多生态使用
+`T-One` + `TestLib`
+### a. 创建 `TestLib` 数据库
+- 进入 mysql docker 镜像，docker exec -it {数据库容器ID} bash
+- 连接数据库：mysql -h 127.0.0.1 -P 3306 -u root -p
+- 创建 TestLib 数据库 testlib
+
+ CREATE DATABASE \`test-lib\` CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
+- 创建 TestLib 数据库表
+### testlib数据库初始化
+
+ 点击展开/折叠脚本
+
+```shell
+
+/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
+/*!40101 SET NAMES utf8 */;
+/*!50503 SET NAMES utf8mb4 */;
+/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
+/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
+
+-- 表 test-lib.case 结构
+CREATE TABLE IF NOT EXISTS `case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试用例名称',
+ `creator` varchar(64) NOT NULL COMMENT '负责人',
+ `type` enum('FUNCTIONAL','PERFORMANCE','STRESS','LOAD','SECURITY','COMPATIBILITY','OTHERS') NOT NULL COMMENT '测试用例类型',
+ `priority` enum('PRIORITY_0','PRIORITY_1','PRIORITY_2','PRIORITY_3') NOT NULL COMMENT '测试用例的优先级',
+ `suite_name` varchar(128) DEFAULT NULL COMMENT '测试套名称',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试用例执行方式,手动、自动',
+ `run_model` enum('SINGLE','CLUSTER') NOT NULL COMMENT '测试用例运行模式,单机、集群',
+ `is_available` tinyint(1) NOT NULL COMMENT '测试用例是否可用',
+ `tone_case` varchar(128) DEFAULT NULL COMMENT 'T-One测试用例，当run_method为自动的时候生效',
+ `device_type` varchar(128) DEFAULT 'unlimit' COMMENT '设备类型,可多选,默认支持所有设备',
+ `device_arch` varchar(256) NOT NULL COMMENT '设备架构类型,可多选,默认支撑所有类型',
+ `labels` varchar(256) DEFAULT NULL COMMENT '设备标签,多个用,隔开',
+ `desc` varchar(512) DEFAULT NULL COMMENT '用例描述',
+ `pre_condition` varchar(512) DEFAULT NULL COMMENT '前置条件',
+ `steps` json DEFAULT NULL COMMENT '操作步骤',
+ `custom_fields` json DEFAULT NULL COMMENT '测试用例扩展属性',
+ `parent` int(11) NOT NULL COMMENT '测试用例分类节点',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`),
+ KEY `ix_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=31 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label 结构
+CREATE TABLE IF NOT EXISTS `case_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '用例标签',
+ `creator` varchar(64) NOT NULL COMMENT '标签创建人',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label_map 结构
+CREATE TABLE IF NOT EXISTS `case_label_map` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_name` varchar(64) NOT NULL COMMENT '用例名称',
+ `case_id` int(11) NOT NULL COMMENT '用例ID',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_label_map_label_name` (`label_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_tree 结构
+CREATE TABLE IF NOT EXISTS `case_tree` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(16) NOT NULL COMMENT '用例结构树节点名称',
+ `parent` int(11) NOT NULL COMMENT '父节点id',
+ `level` int(11) NOT NULL COMMENT '树结构的深度',
+ `path` varchar(128) NOT NULL COMMENT '模块完整路径',
+ `children_nums` int(11) NOT NULL COMMENT '子节点数量',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_tree_path` (`path`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device 结构
+CREATE TABLE IF NOT EXISTS `device` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备名称',
+ `arch` enum('X86','ARCH64','RISCV','LOONGARCH','NOARCH','OTHERS') NOT NULL COMMENT '设备架构',
+ `ip` varchar(16) NOT NULL COMMENT '设备ip',
+ `type` enum('UNLIMIT','VM','DOCKER','PHYSICS') NOT NULL COMMENT '设备类型',
+ `sn` varchar(16) DEFAULT NULL COMMENT '设备序号',
+ `status` tinyint(1) NOT NULL COMMENT '设备是否可用',
+ `label` json DEFAULT NULL COMMENT '设备标签列表数组',
+ `owner` varchar(256) NOT NULL COMMENT '设备负责人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label 结构
+CREATE TABLE IF NOT EXISTS `device_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备标签名称',
+ `color` varchar(32) NOT NULL COMMENT '设备标签颜色',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `ix_device_label_name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label_relationship 结构
+CREATE TABLE IF NOT EXISTS `device_label_relationship` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_id` int(11) NOT NULL COMMENT '机器Label id',
+ `device_id` int(11) NOT NULL COMMENT '机器Label id',
+ `is_delete` tinyint(1) DEFAULT NULL COMMENT '对应关系是否删除',
+ PRIMARY KEY (`id`),
+ KEY `ix_device_label_relationship_device_id` (`device_id`),
+ KEY `ix_device_label_relationship_label_id` (`label_id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.func_result 结构
+CREATE TABLE IF NOT EXISTS `func_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `sub_case_name` varchar(128) NOT NULL COMMENT 'tone job名称',
+ `sub_case_result` enum('SUCCESS','FAIL','SKIP') NOT NULL COMMENT '功能结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `current` json DEFAULT NULL,
+ `expect` json DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_func_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_func_result_task_id` (`task_id`),
+ KEY `ix_func_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_func_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=479 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.outline 结构
+CREATE TABLE IF NOT EXISTS `outline` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试大纲文件名',
+ `title` varchar(128) NOT NULL COMMENT '测试大纲的标题',
+ `owner` varchar(16) NOT NULL COMMENT '测试大纲负责人',
+ `tid` varchar(256) NOT NULL COMMENT 'oss文件地址',
+ `remark` varchar(64) DEFAULT NULL COMMENT '测试大纲备注描述信息',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.perf_result 结构
+CREATE TABLE IF NOT EXISTS `perf_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `metric` varchar(128) NOT NULL COMMENT '指标名称',
+ `test_value` varchar(64) DEFAULT NULL COMMENT '测试值',
+ `cv_value` varchar(64) DEFAULT NULL COMMENT 'cv值',
+ `max_value` varchar(64) DEFAULT NULL COMMENT '最大值',
+ `min_value` varchar(64) DEFAULT NULL COMMENT '最小值',
+ `unit` varchar(64) DEFAULT NULL COMMENT '测试单位',
+ `track_result` enum('NA','INVALID','NORMAL','DECLINE','INCREASE') NOT NULL COMMENT '跟踪结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ PRIMARY KEY (`id`),
+ KEY `ix_perf_result_task_id` (`task_id`),
+ KEY `ix_perf_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_perf_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_perf_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan 结构
+CREATE TABLE IF NOT EXISTS `plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(64) NOT NULL COMMENT '测试方案名称',
+ `req_id` int(11) DEFAULT NULL COMMENT '测试需求id',
+ `req_title` varchar(128) DEFAULT NULL COMMENT '测试需求标题',
+ `content` json DEFAULT NULL COMMENT '测试方案内容',
+ `status` varchar(16) NOT NULL COMMENT '测试方案阶段状态',
+ `cases` varchar(256) DEFAULT NULL COMMENT '测试用例,多个使用","隔开',
+ `tasks` varchar(256) DEFAULT NULL COMMENT '测试任务,多个使用","隔开',
+ `reviewers` varchar(256) NOT NULL COMMENT '方案评审人列表',
+ `owner` varchar(256) NOT NULL COMMENT '测试需求的负责人，多个以,隔开',
+ `report` tinyint(1) NOT NULL COMMENT '测试报告是否已生成',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `title` (`title`)
+) ENGINE=InnoDB AUTO_INCREMENT=63 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan_review 结构
+CREATE TABLE IF NOT EXISTS `plan_review` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `reviewer` varchar(32) NOT NULL COMMENT '测试需方案的评审人',
+ `status` varchar(16) NOT NULL COMMENT '评审状态',
+ `desc` varchar(512) DEFAULT NULL COMMENT '评审内容',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_category 结构
+CREATE TABLE IF NOT EXISTS `product_category` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '大类名称',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_plan 结构
+CREATE TABLE IF NOT EXISTS `product_plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `test_product_id` int(11) NOT NULL COMMENT '测试产品id',
+ `plan_id` int(11) NOT NULL COMMENT '测试产品实际复制执行的plan id',
+ `executor` varchar(256) NOT NULL COMMENT '测试产品执行人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.requirement 结构
+CREATE TABLE IF NOT EXISTS `requirement` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(128) NOT NULL COMMENT '测试需求标题',
+ `outline_id` int(11) DEFAULT NULL COMMENT '测试大纲id',
+ `outline_title` varchar(64) DEFAULT NULL COMMENT '测试大纲标题',
+ `content` json NOT NULL COMMENT '测试需求的描述内容',
+ `status` varchar(16) NOT NULL COMMENT '测试需求阶段',
+ `owner` varchar(16) NOT NULL COMMENT '测试需求的创建人',
+ `assignee` varchar(256) NOT NULL COMMENT '测试需求的指派人，多个以,隔开',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.task 结构
+CREATE TABLE IF NOT EXISTS `task` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '任务名称',
+ `status` varchar(16) NOT NULL COMMENT '任务执行状态',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试任务执行方式',
+ `owner` varchar(256) NOT NULL COMMENT '任务执行人',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `plan_title` varchar(256) NOT NULL COMMENT '测试方案标题',
+ `cases` varchar(256) NOT NULL COMMENT '测试用例,多个使用,隔开',
+ `desc` varchar(256) DEFAULT NULL COMMENT '备注',
+ `run_result` json DEFAULT NULL COMMENT '手动用例执行结果',
+ `config` json DEFAULT NULL COMMENT '测试任务配置',
+ `device_id` int(11) DEFAULT NULL COMMENT '测试设备ID',
+ `device_ip` varchar(256) DEFAULT NULL COMMENT '测试机器IP',
+ `workspace` varchar(128) NOT NULL COMMENT 'tone workspace',
+ `project` varchar(128) NOT NULL COMMENT 'tone project',
+ `job_type` varchar(128) NOT NULL COMMENT 'tone job type',
+ `test_type` varchar(32) DEFAULT 'others' COMMENT '测试任务类型',
+ `cluster` varchar(256) DEFAULT NULL COMMENT '测试机器集群名称',
+ `tags` varchar(256) DEFAULT NULL COMMENT '测试机器标签',
+ `tsn` varchar(256) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_task_plan_id` (`plan_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=90 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_product 结构
+CREATE TABLE IF NOT EXISTS `test_product` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试产品名称',
+ `category_id` int(11) NOT NULL COMMENT '大类id',
+ `origin_plan_id` int(11) NOT NULL COMMENT '测试产品对应的plan id',
+ `desc` varchar(256) DEFAULT NULL COMMENT '产品描述',
+ `test_method` varchar(256) DEFAULT NULL COMMENT '测试方法',
+ `test_requirement` varchar(256) DEFAULT NULL COMMENT '测试要求',
+ `need_config` tinyint(1) DEFAULT NULL COMMENT '是否扩展配置',
+ `owner` varchar(256) NOT NULL DEFAULT '' COMMENT '测试产品创建人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_suite 结构
+CREATE TABLE IF NOT EXISTS `test_suite` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(128) NOT NULL COMMENT '测试套名称',
+ `creator` varchar(64) NOT NULL COMMENT '测试套的创建人员',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_case 结构
+CREATE TABLE IF NOT EXISTS `tone_case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone用例ID',
+ `tone_case_name` varchar(256) NOT NULL COMMENT 'tone用例名称',
+ `suite_id` int(11) NOT NULL COMMENT 'suite ID',
+ `suite_name` varchar(256) NOT NULL COMMENT 'suite用例名称',
+ `test_type` varchar(64) DEFAULT NULL COMMENT '测试类型',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_case_tone_case_name` (`tone_case_name`),
+ KEY `ix_tone_case_suite_id` (`suite_id`),
+ KEY `ix_tone_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=603 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_job 结构
+CREATE TABLE IF NOT EXISTS `tone_job` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(100) NOT NULL COMMENT 'tone job名称',
+ `state` enum('PENDING','RUNNING','SUCCESS','FAIL','STOP','SKIP') NOT NULL COMMENT 'tone job状态',
+ `test_type` enum('FUNCTIONAL','PERFORMANCE') NOT NULL COMMENT '测试类型',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `tone_job_link` varchar(100) DEFAULT '' COMMENT 'tone job链接',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `server_info` json DEFAULT NULL COMMENT '存储tone job的机器信息',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_job_tone_job_id` (`tone_job_id`),
+ KEY `ix_tone_job_task_id` (`task_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=51 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_pull 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_pull` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=76149 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_push 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_push` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user 结构
+CREATE TABLE IF NOT EXISTS `user` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) DEFAULT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ KEY `ix_user_user_name` (`user_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_open_source 结构
+CREATE TABLE IF NOT EXISTS `user_open_source` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) NOT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `password` varchar(64) NOT NULL COMMENT '用户密码,前端对密码md5加密后的值',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ `token` varchar(256) NOT NULL COMMENT 'api访问凭证',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ UNIQUE KEY `email` (`email`),
+ KEY `ix_user_open_source_token` (`token`(255))
+) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_role_op_record 结构
+CREATE TABLE IF NOT EXISTS `user_role_op_record` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `applicant` varchar(64) NOT NULL COMMENT '申请人name',
+ `applicant_id` int(11) NOT NULL COMMENT '申请人ID',
+ `apply_reason` varchar(512) DEFAULT NULL COMMENT '申请理由',
+ `signer` varchar(64) DEFAULT NULL COMMENT '评审人name',
+ `has_review` tinyint(1) NOT NULL COMMENT '是否已经审核',
+ `review_result` enum('INIT','PASS','FAIL') NOT NULL COMMENT '审核结果',
+ `review_reason` varchar(512) DEFAULT NULL COMMENT '评审意见',
+ `method` enum('APPROVE','UPGRADE','DOWNGRADE','DELETE') NOT NULL COMMENT '操作方式',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;
+/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;
+/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
+
+
+```
+
+
+### b.TestLib 服务依赖
+### c. clone test-lib代码到~/tone/code目录下
+```shell
+git clone --single-branch --branch master https://gitee.com/anolis/testlib.git ~/tone/code/testlib
+```
+### d.增加docker-compose配置
+```yaml
+# docker-compose.yaml service下增加test-lib
+ test-lib:
+ build:
+ context: code/testlib/
+ dockerfile: Dockerfile
+ args:
+ APP_NAME: test-lib
+ ENV: daily
+ image: test-lib:latest
+ ports:
+ - "8005:8005"
+ depends_on:
+ - mysql
+ - redis
+ environment:
+ <<: *common-variables
+ # db
+ db_url: mysql+aiomysql://${db_user}:{db_password}@mysql:3306/test-lib
+ # redis
+ redis_url: redis://:${redis_password}@redis:6379/10
+ # app
+ tone_host: http://${server_ip}:8080/
+ tone_token: tone_token
+ tone_user_name: tone_user_name
+ main_domain: http://${server_ip}:8005
+ oss_url: http://${server_ip}:8005
+```
+#### e.重启服务
+```shell
+docker-compose -f ~/tone/docker-compose.yaml up --build -d
+```
+## 7. 独立部署 FAQ
+https://tone.openanolis.cn/help_doc/12
\ No newline at end of file
diff --git "a/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/a\347\224\250\346\210\267\350\201\206\345\220\254-copy/test.md" "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/a\347\224\250\346\210\267\350\201\206\345\220\254-copy/test.md"
new file mode 100644
index 0000000000000000000000000000000000000000..b09df7d02fee342106c45e78485a992609d67bdb
--- /dev/null
+++ "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/a\347\224\250\346\210\267\350\201\206\345\220\254-copy/test.md"
@@ -0,0 +1,70 @@
+# 一级标题
+## 二级标题
+### 三级标题
+**粗体文本**
+
+__cuti__
+
+*斜体文本*
+
+_xieti_
+
+下划线
+
+~~删除线~~
+
+上标：Xy
+
+下标：An
+
+> 引用文本
+- 无序列表项1
+ - 第二层
+- 无序列表项2
+* * *
+1. 有序列表项1
+2. 有序列表项2
+---
+[链接文本](https://gitee.com/suli01/community/edit/master/sig/T-One/content/%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97/%E7%94%A8%E6%88%B7%E8%81%86%E5%90%AC/test.md)
+
+链接名称
+
+'''python
+def hello_world():
+ print("Hello, world!")
+
+
+
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+
+- [x] ：已完成事项
+
+
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+
+- [x] ：已完成事项
+
+
+
+
+ 点击展开/折叠脚本
+
+```shell
+
+/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
+/*!40101 SET NAMES utf8 */;
+/*!50503 SET NAMES utf8mb4 */;
+/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
+/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
+
+-- 表 test-lib.case 结构
+CREATE TABLE IF NOT EXISTS `case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试用例名称',
+ `creator` varchar(64) NOT NULL COMMENT '负责人',
+ `type` enum('FUNCTIONAL','PERFORMANCE','STRESS','LOAD','SECURITY','COMPATIBILITY','OTHERS') NOT NULL COMMENT '测试用例类型',
+ `priority` enum('PRIORITY_0','PRIORITY_1','PRIORITY_2','PRIORITY_3') NOT NULL COMMENT '测试用例的优先级',
+ `suite_name` varchar(128) DEFAULT NULL COMMENT '测试套名称',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试用例执行方式,手动、自动',
+ `run_model` enum('SINGLE','CLUSTER') NOT NULL COMMENT '测试用例运行模式,单机、集群',
+ `is_available` tinyint(1) NOT NULL COMMENT '测试用例是否可用',
+ `tone_case` varchar(128) DEFAULT NULL COMMENT 'T-One测试用例，当run_method为自动的时候生效',
+ `device_type` varchar(128) DEFAULT 'unlimit' COMMENT '设备类型,可多选,默认支持所有设备',
+ `device_arch` varchar(256) NOT NULL COMMENT '设备架构类型,可多选,默认支撑所有类型',
+ `labels` varchar(256) DEFAULT NULL COMMENT '设备标签,多个用,隔开',
+ `desc` varchar(512) DEFAULT NULL COMMENT '用例描述',
+ `pre_condition` varchar(512) DEFAULT NULL COMMENT '前置条件',
+ `steps` json DEFAULT NULL COMMENT '操作步骤',
+ `custom_fields` json DEFAULT NULL COMMENT '测试用例扩展属性',
+ `parent` int(11) NOT NULL COMMENT '测试用例分类节点',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`),
+ KEY `ix_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=31 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label 结构
+CREATE TABLE IF NOT EXISTS `case_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '用例标签',
+ `creator` varchar(64) NOT NULL COMMENT '标签创建人',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label_map 结构
+CREATE TABLE IF NOT EXISTS `case_label_map` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_name` varchar(64) NOT NULL COMMENT '用例名称',
+ `case_id` int(11) NOT NULL COMMENT '用例ID',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_label_map_label_name` (`label_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_tree 结构
+CREATE TABLE IF NOT EXISTS `case_tree` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(16) NOT NULL COMMENT '用例结构树节点名称',
+ `parent` int(11) NOT NULL COMMENT '父节点id',
+ `level` int(11) NOT NULL COMMENT '树结构的深度',
+ `path` varchar(128) NOT NULL COMMENT '模块完整路径',
+ `children_nums` int(11) NOT NULL COMMENT '子节点数量',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_tree_path` (`path`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device 结构
+CREATE TABLE IF NOT EXISTS `device` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备名称',
+ `arch` enum('X86','ARCH64','RISCV','LOONGARCH','NOARCH','OTHERS') NOT NULL COMMENT '设备架构',
+ `ip` varchar(16) NOT NULL COMMENT '设备ip',
+ `type` enum('UNLIMIT','VM','DOCKER','PHYSICS') NOT NULL COMMENT '设备类型',
+ `sn` varchar(16) DEFAULT NULL COMMENT '设备序号',
+ `status` tinyint(1) NOT NULL COMMENT '设备是否可用',
+ `label` json DEFAULT NULL COMMENT '设备标签列表数组',
+ `owner` varchar(256) NOT NULL COMMENT '设备负责人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label 结构
+CREATE TABLE IF NOT EXISTS `device_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备标签名称',
+ `color` varchar(32) NOT NULL COMMENT '设备标签颜色',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `ix_device_label_name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label_relationship 结构
+CREATE TABLE IF NOT EXISTS `device_label_relationship` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_id` int(11) NOT NULL COMMENT '机器Label id',
+ `device_id` int(11) NOT NULL COMMENT '机器Label id',
+ `is_delete` tinyint(1) DEFAULT NULL COMMENT '对应关系是否删除',
+ PRIMARY KEY (`id`),
+ KEY `ix_device_label_relationship_device_id` (`device_id`),
+ KEY `ix_device_label_relationship_label_id` (`label_id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.func_result 结构
+CREATE TABLE IF NOT EXISTS `func_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `sub_case_name` varchar(128) NOT NULL COMMENT 'tone job名称',
+ `sub_case_result` enum('SUCCESS','FAIL','SKIP') NOT NULL COMMENT '功能结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `current` json DEFAULT NULL,
+ `expect` json DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_func_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_func_result_task_id` (`task_id`),
+ KEY `ix_func_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_func_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=479 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.outline 结构
+CREATE TABLE IF NOT EXISTS `outline` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试大纲文件名',
+ `title` varchar(128) NOT NULL COMMENT '测试大纲的标题',
+ `owner` varchar(16) NOT NULL COMMENT '测试大纲负责人',
+ `tid` varchar(256) NOT NULL COMMENT 'oss文件地址',
+ `remark` varchar(64) DEFAULT NULL COMMENT '测试大纲备注描述信息',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.perf_result 结构
+CREATE TABLE IF NOT EXISTS `perf_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `metric` varchar(128) NOT NULL COMMENT '指标名称',
+ `test_value` varchar(64) DEFAULT NULL COMMENT '测试值',
+ `cv_value` varchar(64) DEFAULT NULL COMMENT 'cv值',
+ `max_value` varchar(64) DEFAULT NULL COMMENT '最大值',
+ `min_value` varchar(64) DEFAULT NULL COMMENT '最小值',
+ `unit` varchar(64) DEFAULT NULL COMMENT '测试单位',
+ `track_result` enum('NA','INVALID','NORMAL','DECLINE','INCREASE') NOT NULL COMMENT '跟踪结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ PRIMARY KEY (`id`),
+ KEY `ix_perf_result_task_id` (`task_id`),
+ KEY `ix_perf_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_perf_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_perf_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan 结构
+CREATE TABLE IF NOT EXISTS `plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(64) NOT NULL COMMENT '测试方案名称',
+ `req_id` int(11) DEFAULT NULL COMMENT '测试需求id',
+ `req_title` varchar(128) DEFAULT NULL COMMENT '测试需求标题',
+ `content` json DEFAULT NULL COMMENT '测试方案内容',
+ `status` varchar(16) NOT NULL COMMENT '测试方案阶段状态',
+ `cases` varchar(256) DEFAULT NULL COMMENT '测试用例,多个使用","隔开',
+ `tasks` varchar(256) DEFAULT NULL COMMENT '测试任务,多个使用","隔开',
+ `reviewers` varchar(256) NOT NULL COMMENT '方案评审人列表',
+ `owner` varchar(256) NOT NULL COMMENT '测试需求的负责人，多个以,隔开',
+ `report` tinyint(1) NOT NULL COMMENT '测试报告是否已生成',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `title` (`title`)
+) ENGINE=InnoDB AUTO_INCREMENT=63 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan_review 结构
+CREATE TABLE IF NOT EXISTS `plan_review` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `reviewer` varchar(32) NOT NULL COMMENT '测试需方案的评审人',
+ `status` varchar(16) NOT NULL COMMENT '评审状态',
+ `desc` varchar(512) DEFAULT NULL COMMENT '评审内容',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_category 结构
+CREATE TABLE IF NOT EXISTS `product_category` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '大类名称',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_plan 结构
+CREATE TABLE IF NOT EXISTS `product_plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `test_product_id` int(11) NOT NULL COMMENT '测试产品id',
+ `plan_id` int(11) NOT NULL COMMENT '测试产品实际复制执行的plan id',
+ `executor` varchar(256) NOT NULL COMMENT '测试产品执行人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.requirement 结构
+CREATE TABLE IF NOT EXISTS `requirement` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(128) NOT NULL COMMENT '测试需求标题',
+ `outline_id` int(11) DEFAULT NULL COMMENT '测试大纲id',
+ `outline_title` varchar(64) DEFAULT NULL COMMENT '测试大纲标题',
+ `content` json NOT NULL COMMENT '测试需求的描述内容',
+ `status` varchar(16) NOT NULL COMMENT '测试需求阶段',
+ `owner` varchar(16) NOT NULL COMMENT '测试需求的创建人',
+ `assignee` varchar(256) NOT NULL COMMENT '测试需求的指派人，多个以,隔开',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.task 结构
+CREATE TABLE IF NOT EXISTS `task` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '任务名称',
+ `status` varchar(16) NOT NULL COMMENT '任务执行状态',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试任务执行方式',
+ `owner` varchar(256) NOT NULL COMMENT '任务执行人',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `plan_title` varchar(256) NOT NULL COMMENT '测试方案标题',
+ `cases` varchar(256) NOT NULL COMMENT '测试用例,多个使用,隔开',
+ `desc` varchar(256) DEFAULT NULL COMMENT '备注',
+ `run_result` json DEFAULT NULL COMMENT '手动用例执行结果',
+ `config` json DEFAULT NULL COMMENT '测试任务配置',
+ `device_id` int(11) DEFAULT NULL COMMENT '测试设备ID',
+ `device_ip` varchar(256) DEFAULT NULL COMMENT '测试机器IP',
+ `workspace` varchar(128) NOT NULL COMMENT 'tone workspace',
+ `project` varchar(128) NOT NULL COMMENT 'tone project',
+ `job_type` varchar(128) NOT NULL COMMENT 'tone job type',
+ `test_type` varchar(32) DEFAULT 'others' COMMENT '测试任务类型',
+ `cluster` varchar(256) DEFAULT NULL COMMENT '测试机器集群名称',
+ `tags` varchar(256) DEFAULT NULL COMMENT '测试机器标签',
+ `tsn` varchar(256) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_task_plan_id` (`plan_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=90 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_product 结构
+CREATE TABLE IF NOT EXISTS `test_product` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试产品名称',
+ `category_id` int(11) NOT NULL COMMENT '大类id',
+ `origin_plan_id` int(11) NOT NULL COMMENT '测试产品对应的plan id',
+ `desc` varchar(256) DEFAULT NULL COMMENT '产品描述',
+ `test_method` varchar(256) DEFAULT NULL COMMENT '测试方法',
+ `test_requirement` varchar(256) DEFAULT NULL COMMENT '测试要求',
+ `need_config` tinyint(1) DEFAULT NULL COMMENT '是否扩展配置',
+ `owner` varchar(256) NOT NULL DEFAULT '' COMMENT '测试产品创建人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_suite 结构
+CREATE TABLE IF NOT EXISTS `test_suite` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(128) NOT NULL COMMENT '测试套名称',
+ `creator` varchar(64) NOT NULL COMMENT '测试套的创建人员',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_case 结构
+CREATE TABLE IF NOT EXISTS `tone_case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone用例ID',
+ `tone_case_name` varchar(256) NOT NULL COMMENT 'tone用例名称',
+ `suite_id` int(11) NOT NULL COMMENT 'suite ID',
+ `suite_name` varchar(256) NOT NULL COMMENT 'suite用例名称',
+ `test_type` varchar(64) DEFAULT NULL COMMENT '测试类型',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_case_tone_case_name` (`tone_case_name`),
+ KEY `ix_tone_case_suite_id` (`suite_id`),
+ KEY `ix_tone_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=603 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_job 结构
+CREATE TABLE IF NOT EXISTS `tone_job` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(100) NOT NULL COMMENT 'tone job名称',
+ `state` enum('PENDING','RUNNING','SUCCESS','FAIL','STOP','SKIP') NOT NULL COMMENT 'tone job状态',
+ `test_type` enum('FUNCTIONAL','PERFORMANCE') NOT NULL COMMENT '测试类型',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `tone_job_link` varchar(100) DEFAULT '' COMMENT 'tone job链接',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `server_info` json DEFAULT NULL COMMENT '存储tone job的机器信息',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_job_tone_job_id` (`tone_job_id`),
+ KEY `ix_tone_job_task_id` (`task_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=51 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_pull 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_pull` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=76149 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_push 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_push` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user 结构
+CREATE TABLE IF NOT EXISTS `user` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) DEFAULT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ KEY `ix_user_user_name` (`user_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_open_source 结构
+CREATE TABLE IF NOT EXISTS `user_open_source` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) NOT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `password` varchar(64) NOT NULL COMMENT '用户密码,前端对密码md5加密后的值',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ `token` varchar(256) NOT NULL COMMENT 'api访问凭证',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ UNIQUE KEY `email` (`email`),
+ KEY `ix_user_open_source_token` (`token`(255))
+) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_role_op_record 结构
+CREATE TABLE IF NOT EXISTS `user_role_op_record` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `applicant` varchar(64) NOT NULL COMMENT '申请人name',
+ `applicant_id` int(11) NOT NULL COMMENT '申请人ID',
+ `apply_reason` varchar(512) DEFAULT NULL COMMENT '申请理由',
+ `signer` varchar(64) DEFAULT NULL COMMENT '评审人name',
+ `has_review` tinyint(1) NOT NULL COMMENT '是否已经审核',
+ `review_result` enum('INIT','PASS','FAIL') NOT NULL COMMENT '审核结果',
+ `review_reason` varchar(512) DEFAULT NULL COMMENT '评审意见',
+ `method` enum('APPROVE','UPGRADE','DOWNGRADE','DELETE') NOT NULL COMMENT '操作方式',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;
+/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;
+/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
+
+
+```
+
+
+### b.TestLib 服务依赖
+### c. clone test-lib代码到~/tone/code目录下
+```shell
+git clone --single-branch --branch master https://gitee.com/anolis/testlib.git ~/tone/code/testlib
+```
+### d.增加docker-compose配置
+```yaml
+# docker-compose.yaml service下增加test-lib
+ test-lib:
+ build:
+ context: code/testlib/
+ dockerfile: Dockerfile
+ args:
+ APP_NAME: test-lib
+ ENV: daily
+ image: test-lib:latest
+ ports:
+ - "8005:8005"
+ depends_on:
+ - mysql
+ - redis
+ environment:
+ <<: *common-variables
+ # db
+ db_url: mysql+aiomysql://${db_user}:{db_password}@mysql:3306/test-lib
+ # redis
+ redis_url: redis://:${redis_password}@redis:6379/10
+ # app
+ tone_host: http://${server_ip}:8080/
+ tone_token: tone_token
+ tone_user_name: tone_user_name
+ main_domain: http://${server_ip}:8005
+ oss_url: http://${server_ip}:8005
+```
+#### e.重启服务
+```shell
+docker-compose -f ~/tone/docker-compose.yaml up --build -d
+```
+## 7. 独立部署 FAQ
+https://tone.openanolis.cn/help_doc/12
\ No newline at end of file
diff --git "a/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/\347\224\250\346\210\267\350\201\206\345\220\254/test.md" "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/\347\224\250\346\210\267\350\201\206\345\220\254/test.md"
new file mode 100644
index 0000000000000000000000000000000000000000..b09df7d02fee342106c45e78485a992609d67bdb
--- /dev/null
+++ "b/sig/T-One-copy2/content/\347\224\250\346\210\267\346\214\207\345\215\227/\347\224\250\346\210\267\350\201\206\345\220\254/test.md"
@@ -0,0 +1,70 @@
+# 一级标题
+## 二级标题
+### 三级标题
+**粗体文本**
+
+__cuti__
+
+*斜体文本*
+
+_xieti_
+
+下划线
+
+~~删除线~~
+
+上标：Xy
+
+下标：An
+
+> 引用文本
+- 无序列表项1
+ - 第二层
+- 无序列表项2
+* * *
+1. 有序列表项1
+2. 有序列表项2
+---
+[链接文本](https://gitee.com/suli01/community/edit/master/sig/T-One/content/%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97/%E7%94%A8%E6%88%B7%E8%81%86%E5%90%AC/test.md)
+
+链接名称
+
+'''python
+def hello_world():
+ print("Hello, world!")
+
+
+
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+
+- [x] ：已完成事项
+
+
+
+
+
+网迅网卡已经按此流程合入 ANCK ：
+- 支持ANCK-5.10 10GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/540
+- 支持ANCK-4.19 10GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/709
+- 支持ANCK-4.19 1GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/1043
+- 支持ANCK-5.10 1GB 网迅网卡驱动: https://gitee.com/anolis/cloud-kernel/pulls/1063
+
+# 重要议题
+- 讨论并决策了将 ANCK-5.10 作为 Anolis8 的默认产品化内核，详情请点击[这里](https://gitee.com/anolis/community/blob/master/proposals/Anolis8%E4%B8%8AANCK-5.10%E4%BA%A7%E5%93%81%E5%8C%96%E7%9A%84%E6%8F%90%E8%AE%AE.md)。
+- 讨论并决策了将 ANCK-5.10 作为 Anolis23 的当前默认内核，详情请点击[这里](https://gitee.com/anolis/community/blob/master/proposals/anck-5.10%E4%BD%9C%E4%B8%BAanolis23%E7%9A%84%E5%86%85%E6%A0%B8%E9%80%89%E5%9E%8B%E7%9A%84%E6%8F%90%E8%AE%AE.md)。
+
+# 运营活动
+- [浪潮信息正式发布基于龙蜥 Anolis OS 的服务器操作系统 Inspur KOS](https://openanolis.cn/news/726244284765327879)。
+- 于2022.12.24 举办了“[龙蜥走进系列活动之走进浪潮信息 MeetUp](https://mp.weixin.qq.com/s?__biz=Mzg4MTMyMTUwMQ==&mid=2247510368&idx=1&sn=95a1d511b32670f8388745682483046a&chksm=cf655a12f812d30494be938d7bf8a46b7244711c8fb75f44e8379ab261b1fd4aeb1c8bb0805e&scene=21#wechat_redirect)"，并成立了浪潮信息龙蜥联合实验室，致力于共建龙蜥社区的软硬件兼容性生态、标准建设和技术创新等。
diff --git "a/sig/T-One-copy3/content/\346\234\210\346\212\245/202301.md" "b/sig/T-One-copy3/content/\346\234\210\346\212\245/202301.md"
new file mode 100644
index 0000000000000000000000000000000000000000..85bbb428461066b1774f93d5ede99390bf2bc702
--- /dev/null
+++ "b/sig/T-One-copy3/content/\346\234\210\346\212\245/202301.md"
@@ -0,0 +1,101 @@
+# 整体进展
+
+- 发布 ANCK 5.10-013 版本。
+- 确定KABI机制整体方案。
+- 浪潮信息龙蜥联合实验室的工作事项更新。
+
+# ANCK 5.10-013 版本
+
+## 内核更新
+
+- 版本更新至 5.10.134-13
+- 重要内核缺陷及安全漏洞(CVE)修复
+- 支持用户态/dev/ioasid
+- SWIOTLB机制性能优化
+- virtio-net 打开 napi.tx 优化 TCP Small Queue 性能
+- 支持AST2600 PCIe 2D VGA Driver
+- 支持FT2500处理器
+- 支持动态开启Group identity特性
+- arm64平台默认内核启动cmdline调整
+- 添加 Compact Numa Aware (CNA) spinlock 功能支持
+- 丰富arm64的perf mem和perf c2c功能
+- fsck.xfs 支持日志恢复
+- hugetext自适应按需大页
+- 支持SGX动态内存管理
+- 使能wireguard模块
+
+## CVE修复列表
+
+详情请参考：
+
+- [Anolis OS 7](https://anas.openanolis.cn/errata/detail/ANSA-2023:0002)
+- [Anolis OS 8](https://anas.openanolis.cn/errata/detail/ANSA-2023:0001)
+
+重要CVE列表:
+
+- CVE-2021-4037
+- CVE-2022-0171
+- CVE-2022-1679
+- CVE-2022-2585
+- CVE-2022-2586
+- CVE-2022-2588
+- CVE-2022-2602
+- CVE-2022-26373
+- CVE-2022-2663
+- CVE-2022-2905
+- CVE-2022-2978
+- CVE-2022-3028
+- CVE-2022-3061
+- CVE-2022-3169
+- CVE-2022-3176
+- CVE-2022-3435
+- CVE-2022-3521
+- CVE-2022-3524
+- CVE-2022-3534
+- CVE-2022-3535
+- CVE-2022-3542
+- CVE-2022-3545
+- CVE-2022-3564
+- CVE-2022-3565
+- CVE-2022-3566
+- CVE-2022-3567
+- CVE-2022-3586
+- CVE-2022-3594
+- CVE-2022-3621
+- CVE-2022-3623
+- CVE-2022-3625
+- CVE-2022-3628
+- CVE-2022-3629
+- CVE-2022-3633
+- CVE-2022-3635
+- CVE-2022-3646
+- CVE-2022-3649
+- CVE-2022-36946
+- CVE-2022-39189
+- CVE-2022-39190
+- CVE-2022-39842
+- CVE-2022-40307
+- CVE-2022-40768
+- CVE-2022-41222
+- CVE-2022-41674
+- CVE-2022-42719
+- CVE-2022-42720
+- CVE-2022-42721
+- CVE-2022-42722
+- CVE-2022-42895
+- CVE-2022-42896
+- CVE-2022-43750
+- CVE-2022-4378
+
+# 龙蜥社区第三方驱动
+
+* 提供主流GPU在AnolisOS的Driver、CUDA、cuDNN安装测试与卸载指导文档：https://openanolis.cn/sig/AI_SIG/doc/721423765456666646
+
+# 重要议题
+
+- 调研并讨论了KABI机制的整体方案与实现细节。
+- 基于浪潮信息龙蜥联合实验室，讨论了关于整机硬件兼容性的相关事项，后续长期共建 AnolisOS 硬件兼容性标准和生态。
+
+# 运营活动
+
+- 无
diff --git "a/sig/T-One-copy3/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md" "b/sig/T-One-copy3/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md"
new file mode 100644
index 0000000000000000000000000000000000000000..30020428d41c0b35e0eb225c6a3b4a4a06f385a6
--- /dev/null
+++ "b/sig/T-One-copy3/content/\346\234\210\346\212\245/\346\234\210\346\212\245\350\257\264\346\230\216.md"
@@ -0,0 +1,7 @@
+- 每月的月初总结发出上月的报告，并更新到 SIG 页面，如 2022.12
+
+- 月报包含内容：
+ + 整体进展：SIG 该月的亮点特性汇总。
+ + 具体进展：SIG 该月项目的详细进展，分别展开细节。
+ + 重要议题: SIG 该月讨论的重要议题。
+ + 运营活动: SIG 该月发生的运营活动。
diff --git "a/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/000000000130_anolis.jpg" "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/000000000130_anolis.jpg"
new file mode 100644
index 0000000000000000000000000000000000000000..25e606c9c5d28fccaf9f6caa351e3720570e4162
Binary files /dev/null and "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/000000000130_anolis.jpg" differ
diff --git "a/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/T-One\346\246\202\350\277\260.md" "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/T-One\346\246\202\350\277\260.md"
new file mode 100644
index 0000000000000000000000000000000000000000..74f3dbc4638e7e414a44eba81a927b219691bc3a
--- /dev/null
+++ "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/T-One\346\246\202\350\277\260.md"
@@ -0,0 +1,30 @@
+### T- One是什么
+ T-One是一站式的自动化质量协作平台；打通了测试计划、测试准备、测试执行、测试分析、测试报告、覆盖率检测、智能Bisect，环境服务等流程的闭环，为社区研发提供一站式质量服务。
+
+
+### 平台架构
+
+
+### 核心特点
+- 一站式质量平台：平台打通了测试准备、测试执行、测试分析、测试计划、测试报告、覆盖率检测、智能Bisect、智能巡检等流程全闭环，为社区研发提供一站式测试支撑。
+ - 支持多CPU混合架构（x86、arm、loogarch、risc-v）
+ - 支持多操作系统类型（龙蜥OS、centos、debian等）
+ - 支持复杂环境测试（企业内网、独立隔离、弹性云虚拟机/容器、应用集群及多种混合环境）
+
+- 质量协作能力：通过分布式的业务架构和独立租户空间能力，支持多企业、多团队的质量协作模式。
+- 数据分析能力：平台提供了时序分析、对比分析，以及聚合生成测试报告的能力，在大量测试之后对数据进行分析以发现软件问题。
+- 开源软件包CI服务：社区开发者可以将自己的软件包(可来自代码托管平台如github/gitee/codeup等)注册到Testfarm, 平台会监控软件包的代码变更，一旦有变更则会立即触发测试，并将测试结果通知开发者，方便开源软件包引入。
+- 开发者资源服务：社区开发者可以reserve测试环境并登陆，方便在测试环境中进行测试及debug。
+- 缺陷定位诊断服务：对于发现的软件缺陷，平台可以提供了缺陷的自动化定位诊断能力，可以发现引入缺陷的commit地址。
+
+
+### 应用场景
+- 场景1：OS发布测试，每次AnolisOS的发布，社区测试团队会根据发布测试策略进行大规模测试，保障产品发布质量，外部用户可以在Testfarm查看发布测试数据。
+- 场景2：开源软件包CI，社区开发者可以将软件包注册到平台，平台会自动监控软件包的变更，一旦发生变更会立即进行测试并推送测试结果。
+- 场景3：自定义测试，社区开发者根据自己的需求可以在T-One平台进行在线测试，或者使用命令行测试。
+- 场景4：离线测试，对于网络不可达的测试环境，用户可以使用离线测试模式测试并上传数据。
+- 场景5：独立部署，外部用户也可以在自己环境下独立部署平台，测试并上传数据到Testfarm。
+- 场景6：登陆测试环境，社区开发者可以根据需要reserve测试环境登陆进行测试及debug。
+- 场景7：缺陷定位诊断，一旦测试出缺陷，平台会自动诊断缺陷引入的commit。
+
+
diff --git "a/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/Dingtalk_20240614165831.jpg" "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/Dingtalk_20240614165831.jpg"
new file mode 100644
index 0000000000000000000000000000000000000000..925bf2945891170613821e8e7dbc9e4206d17c8d
Binary files /dev/null and "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/Dingtalk_20240614165831.jpg" differ
diff --git "a/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/jiagou.jpeg" "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/jiagou.jpeg"
new file mode 100644
index 0000000000000000000000000000000000000000..392076fe21eafd908c238ff0e851862e84a05a2d
Binary files /dev/null and "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/assets/jiagou.jpeg" differ
diff --git "a/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/a\347\224\250\346\210\267\350\201\206\345\220\254-cpoy/test.md" "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/a\347\224\250\346\210\267\350\201\206\345\220\254-cpoy/test.md"
new file mode 100644
index 0000000000000000000000000000000000000000..b09df7d02fee342106c45e78485a992609d67bdb
--- /dev/null
+++ "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/a\347\224\250\346\210\267\350\201\206\345\220\254-cpoy/test.md"
@@ -0,0 +1,70 @@
+# 一级标题
+## 二级标题
+### 三级标题
+**粗体文本**
+
+__cuti__
+
+*斜体文本*
+
+_xieti_
+
+下划线
+
+~~删除线~~
+
+上标：Xy
+
+下标：An
+
+> 引用文本
+- 无序列表项1
+ - 第二层
+- 无序列表项2
+* * *
+1. 有序列表项1
+2. 有序列表项2
+---
+[链接文本](https://gitee.com/suli01/community/edit/master/sig/T-One/content/%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97/%E7%94%A8%E6%88%B7%E8%81%86%E5%90%AC/test.md)
+
+链接名称
+
+'''python
+def hello_world():
+ print("Hello, world!")
+
+
+
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+
+- [x] ：已完成事项
+
+
+
+
+ 点击展开/折叠脚本
+
+```shell
+
+/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
+/*!40101 SET NAMES utf8 */;
+/*!50503 SET NAMES utf8mb4 */;
+/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
+/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
+
+-- 表 test-lib.case 结构
+CREATE TABLE IF NOT EXISTS `case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试用例名称',
+ `creator` varchar(64) NOT NULL COMMENT '负责人',
+ `type` enum('FUNCTIONAL','PERFORMANCE','STRESS','LOAD','SECURITY','COMPATIBILITY','OTHERS') NOT NULL COMMENT '测试用例类型',
+ `priority` enum('PRIORITY_0','PRIORITY_1','PRIORITY_2','PRIORITY_3') NOT NULL COMMENT '测试用例的优先级',
+ `suite_name` varchar(128) DEFAULT NULL COMMENT '测试套名称',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试用例执行方式,手动、自动',
+ `run_model` enum('SINGLE','CLUSTER') NOT NULL COMMENT '测试用例运行模式,单机、集群',
+ `is_available` tinyint(1) NOT NULL COMMENT '测试用例是否可用',
+ `tone_case` varchar(128) DEFAULT NULL COMMENT 'T-One测试用例，当run_method为自动的时候生效',
+ `device_type` varchar(128) DEFAULT 'unlimit' COMMENT '设备类型,可多选,默认支持所有设备',
+ `device_arch` varchar(256) NOT NULL COMMENT '设备架构类型,可多选,默认支撑所有类型',
+ `labels` varchar(256) DEFAULT NULL COMMENT '设备标签,多个用,隔开',
+ `desc` varchar(512) DEFAULT NULL COMMENT '用例描述',
+ `pre_condition` varchar(512) DEFAULT NULL COMMENT '前置条件',
+ `steps` json DEFAULT NULL COMMENT '操作步骤',
+ `custom_fields` json DEFAULT NULL COMMENT '测试用例扩展属性',
+ `parent` int(11) NOT NULL COMMENT '测试用例分类节点',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`),
+ KEY `ix_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=31 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label 结构
+CREATE TABLE IF NOT EXISTS `case_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '用例标签',
+ `creator` varchar(64) NOT NULL COMMENT '标签创建人',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_label_map 结构
+CREATE TABLE IF NOT EXISTS `case_label_map` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_name` varchar(64) NOT NULL COMMENT '用例名称',
+ `case_id` int(11) NOT NULL COMMENT '用例ID',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_label_map_label_name` (`label_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.case_tree 结构
+CREATE TABLE IF NOT EXISTS `case_tree` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(16) NOT NULL COMMENT '用例结构树节点名称',
+ `parent` int(11) NOT NULL COMMENT '父节点id',
+ `level` int(11) NOT NULL COMMENT '树结构的深度',
+ `path` varchar(128) NOT NULL COMMENT '模块完整路径',
+ `children_nums` int(11) NOT NULL COMMENT '子节点数量',
+ PRIMARY KEY (`id`),
+ KEY `ix_case_tree_path` (`path`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device 结构
+CREATE TABLE IF NOT EXISTS `device` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备名称',
+ `arch` enum('X86','ARCH64','RISCV','LOONGARCH','NOARCH','OTHERS') NOT NULL COMMENT '设备架构',
+ `ip` varchar(16) NOT NULL COMMENT '设备ip',
+ `type` enum('UNLIMIT','VM','DOCKER','PHYSICS') NOT NULL COMMENT '设备类型',
+ `sn` varchar(16) DEFAULT NULL COMMENT '设备序号',
+ `status` tinyint(1) NOT NULL COMMENT '设备是否可用',
+ `label` json DEFAULT NULL COMMENT '设备标签列表数组',
+ `owner` varchar(256) NOT NULL COMMENT '设备负责人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label 结构
+CREATE TABLE IF NOT EXISTS `device_label` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '设备标签名称',
+ `color` varchar(32) NOT NULL COMMENT '设备标签颜色',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `ix_device_label_name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.device_label_relationship 结构
+CREATE TABLE IF NOT EXISTS `device_label_relationship` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `label_id` int(11) NOT NULL COMMENT '机器Label id',
+ `device_id` int(11) NOT NULL COMMENT '机器Label id',
+ `is_delete` tinyint(1) DEFAULT NULL COMMENT '对应关系是否删除',
+ PRIMARY KEY (`id`),
+ KEY `ix_device_label_relationship_device_id` (`device_id`),
+ KEY `ix_device_label_relationship_label_id` (`label_id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.func_result 结构
+CREATE TABLE IF NOT EXISTS `func_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `sub_case_name` varchar(128) NOT NULL COMMENT 'tone job名称',
+ `sub_case_result` enum('SUCCESS','FAIL','SKIP') NOT NULL COMMENT '功能结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `current` json DEFAULT NULL,
+ `expect` json DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_func_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_func_result_task_id` (`task_id`),
+ KEY `ix_func_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_func_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=479 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.outline 结构
+CREATE TABLE IF NOT EXISTS `outline` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试大纲文件名',
+ `title` varchar(128) NOT NULL COMMENT '测试大纲的标题',
+ `owner` varchar(16) NOT NULL COMMENT '测试大纲负责人',
+ `tid` varchar(256) NOT NULL COMMENT 'oss文件地址',
+ `remark` varchar(64) DEFAULT NULL COMMENT '测试大纲备注描述信息',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.perf_result 结构
+CREATE TABLE IF NOT EXISTS `perf_result` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `metric` varchar(128) NOT NULL COMMENT '指标名称',
+ `test_value` varchar(64) DEFAULT NULL COMMENT '测试值',
+ `cv_value` varchar(64) DEFAULT NULL COMMENT 'cv值',
+ `max_value` varchar(64) DEFAULT NULL COMMENT '最大值',
+ `min_value` varchar(64) DEFAULT NULL COMMENT '最小值',
+ `unit` varchar(64) DEFAULT NULL COMMENT '测试单位',
+ `track_result` enum('NA','INVALID','NORMAL','DECLINE','INCREASE') NOT NULL COMMENT '跟踪结果',
+ `tone_suite_id` int(11) NOT NULL COMMENT 'suite id',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone case id',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ PRIMARY KEY (`id`),
+ KEY `ix_perf_result_task_id` (`task_id`),
+ KEY `ix_perf_result_tone_case_id` (`tone_case_id`),
+ KEY `ix_perf_result_tone_suite_id` (`tone_suite_id`),
+ KEY `ix_perf_result_tone_job_id` (`tone_job_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan 结构
+CREATE TABLE IF NOT EXISTS `plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(64) NOT NULL COMMENT '测试方案名称',
+ `req_id` int(11) DEFAULT NULL COMMENT '测试需求id',
+ `req_title` varchar(128) DEFAULT NULL COMMENT '测试需求标题',
+ `content` json DEFAULT NULL COMMENT '测试方案内容',
+ `status` varchar(16) NOT NULL COMMENT '测试方案阶段状态',
+ `cases` varchar(256) DEFAULT NULL COMMENT '测试用例,多个使用","隔开',
+ `tasks` varchar(256) DEFAULT NULL COMMENT '测试任务,多个使用","隔开',
+ `reviewers` varchar(256) NOT NULL COMMENT '方案评审人列表',
+ `owner` varchar(256) NOT NULL COMMENT '测试需求的负责人，多个以,隔开',
+ `report` tinyint(1) NOT NULL COMMENT '测试报告是否已生成',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `title` (`title`)
+) ENGINE=InnoDB AUTO_INCREMENT=63 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.plan_review 结构
+CREATE TABLE IF NOT EXISTS `plan_review` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `reviewer` varchar(32) NOT NULL COMMENT '测试需方案的评审人',
+ `status` varchar(16) NOT NULL COMMENT '评审状态',
+ `desc` varchar(512) DEFAULT NULL COMMENT '评审内容',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_category 结构
+CREATE TABLE IF NOT EXISTS `product_category` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '大类名称',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.product_plan 结构
+CREATE TABLE IF NOT EXISTS `product_plan` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `test_product_id` int(11) NOT NULL COMMENT '测试产品id',
+ `plan_id` int(11) NOT NULL COMMENT '测试产品实际复制执行的plan id',
+ `executor` varchar(256) NOT NULL COMMENT '测试产品执行人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.requirement 结构
+CREATE TABLE IF NOT EXISTS `requirement` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `title` varchar(128) NOT NULL COMMENT '测试需求标题',
+ `outline_id` int(11) DEFAULT NULL COMMENT '测试大纲id',
+ `outline_title` varchar(64) DEFAULT NULL COMMENT '测试大纲标题',
+ `content` json NOT NULL COMMENT '测试需求的描述内容',
+ `status` varchar(16) NOT NULL COMMENT '测试需求阶段',
+ `owner` varchar(16) NOT NULL COMMENT '测试需求的创建人',
+ `assignee` varchar(256) NOT NULL COMMENT '测试需求的指派人，多个以,隔开',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.task 结构
+CREATE TABLE IF NOT EXISTS `task` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '任务名称',
+ `status` varchar(16) NOT NULL COMMENT '任务执行状态',
+ `run_method` enum('MANUAL','AUTO') NOT NULL COMMENT '测试任务执行方式',
+ `owner` varchar(256) NOT NULL COMMENT '任务执行人',
+ `plan_id` int(11) NOT NULL COMMENT '测试方案id',
+ `plan_title` varchar(256) NOT NULL COMMENT '测试方案标题',
+ `cases` varchar(256) NOT NULL COMMENT '测试用例,多个使用,隔开',
+ `desc` varchar(256) DEFAULT NULL COMMENT '备注',
+ `run_result` json DEFAULT NULL COMMENT '手动用例执行结果',
+ `config` json DEFAULT NULL COMMENT '测试任务配置',
+ `device_id` int(11) DEFAULT NULL COMMENT '测试设备ID',
+ `device_ip` varchar(256) DEFAULT NULL COMMENT '测试机器IP',
+ `workspace` varchar(128) NOT NULL COMMENT 'tone workspace',
+ `project` varchar(128) NOT NULL COMMENT 'tone project',
+ `job_type` varchar(128) NOT NULL COMMENT 'tone job type',
+ `test_type` varchar(32) DEFAULT 'others' COMMENT '测试任务类型',
+ `cluster` varchar(256) DEFAULT NULL COMMENT '测试机器集群名称',
+ `tags` varchar(256) DEFAULT NULL COMMENT '测试机器标签',
+ `tsn` varchar(256) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `ix_task_plan_id` (`plan_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=90 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_product 结构
+CREATE TABLE IF NOT EXISTS `test_product` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(64) NOT NULL COMMENT '测试产品名称',
+ `category_id` int(11) NOT NULL COMMENT '大类id',
+ `origin_plan_id` int(11) NOT NULL COMMENT '测试产品对应的plan id',
+ `desc` varchar(256) DEFAULT NULL COMMENT '产品描述',
+ `test_method` varchar(256) DEFAULT NULL COMMENT '测试方法',
+ `test_requirement` varchar(256) DEFAULT NULL COMMENT '测试要求',
+ `need_config` tinyint(1) DEFAULT NULL COMMENT '是否扩展配置',
+ `owner` varchar(256) NOT NULL DEFAULT '' COMMENT '测试产品创建人',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.test_suite 结构
+CREATE TABLE IF NOT EXISTS `test_suite` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(128) NOT NULL COMMENT '测试套名称',
+ `creator` varchar(64) NOT NULL COMMENT '测试套的创建人员',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `name` (`name`)
+) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_case 结构
+CREATE TABLE IF NOT EXISTS `tone_case` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `tone_case_id` int(11) NOT NULL COMMENT 'tone用例ID',
+ `tone_case_name` varchar(256) NOT NULL COMMENT 'tone用例名称',
+ `suite_id` int(11) NOT NULL COMMENT 'suite ID',
+ `suite_name` varchar(256) NOT NULL COMMENT 'suite用例名称',
+ `test_type` varchar(64) DEFAULT NULL COMMENT '测试类型',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_case_tone_case_name` (`tone_case_name`),
+ KEY `ix_tone_case_suite_id` (`suite_id`),
+ KEY `ix_tone_case_suite_name` (`suite_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=603 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_job 结构
+CREATE TABLE IF NOT EXISTS `tone_job` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `name` varchar(100) NOT NULL COMMENT 'tone job名称',
+ `state` enum('PENDING','RUNNING','SUCCESS','FAIL','STOP','SKIP') NOT NULL COMMENT 'tone job状态',
+ `test_type` enum('FUNCTIONAL','PERFORMANCE') NOT NULL COMMENT '测试类型',
+ `tone_job_id` int(11) NOT NULL COMMENT 'tone job id',
+ `tone_job_link` varchar(100) DEFAULT '' COMMENT 'tone job链接',
+ `task_id` int(11) NOT NULL COMMENT '测试方案id',
+ `server_info` json DEFAULT NULL COMMENT '存储tone job的机器信息',
+ PRIMARY KEY (`id`),
+ KEY `ix_tone_job_tone_job_id` (`tone_job_id`),
+ KEY `ix_tone_job_task_id` (`task_id`)
+) ENGINE=InnoDB AUTO_INCREMENT=51 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_pull 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_pull` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=76149 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.tone_sync_push 结构
+CREATE TABLE IF NOT EXISTS `tone_sync_push` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user 结构
+CREATE TABLE IF NOT EXISTS `user` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) DEFAULT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ KEY `ix_user_user_name` (`user_name`)
+) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_open_source 结构
+CREATE TABLE IF NOT EXISTS `user_open_source` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `user_name` varchar(256) DEFAULT NULL COMMENT '用户名称',
+ `nick_name` varchar(64) NOT NULL COMMENT '用户昵称,具有唯一性',
+ `email` varchar(64) NOT NULL COMMENT '用户邮箱',
+ `password` varchar(64) NOT NULL COMMENT '用户密码,前端对密码md5加密后的值',
+ `avatar_url` varchar(512) DEFAULT NULL COMMENT '用户头像地址',
+ `role` enum('ADMIN','SENIOR','JUNIOR','COMMON') NOT NULL DEFAULT 'COMMON',
+ `token` varchar(256) NOT NULL COMMENT 'api访问凭证',
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `nick_name` (`nick_name`),
+ UNIQUE KEY `email` (`email`),
+ KEY `ix_user_open_source_token` (`token`(255))
+) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;
+
+-- 表 test-lib.user_role_op_record 结构
+CREATE TABLE IF NOT EXISTS `user_role_op_record` (
+ `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键自增id',
+ `gmt_created` datetime DEFAULT NULL COMMENT '创建时间',
+ `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
+ `applicant` varchar(64) NOT NULL COMMENT '申请人name',
+ `applicant_id` int(11) NOT NULL COMMENT '申请人ID',
+ `apply_reason` varchar(512) DEFAULT NULL COMMENT '申请理由',
+ `signer` varchar(64) DEFAULT NULL COMMENT '评审人name',
+ `has_review` tinyint(1) NOT NULL COMMENT '是否已经审核',
+ `review_result` enum('INIT','PASS','FAIL') NOT NULL COMMENT '审核结果',
+ `review_reason` varchar(512) DEFAULT NULL COMMENT '评审意见',
+ `method` enum('APPROVE','UPGRADE','DOWNGRADE','DELETE') NOT NULL COMMENT '操作方式',
+ PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
+
+/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;
+/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;
+/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
+
+
+```
+
+
+### b.TestLib 服务依赖
+### c. clone test-lib代码到~/tone/code目录下
+```shell
+git clone --single-branch --branch master https://gitee.com/anolis/testlib.git ~/tone/code/testlib
+```
+### d.增加docker-compose配置
+```yaml
+# docker-compose.yaml service下增加test-lib
+ test-lib:
+ build:
+ context: code/testlib/
+ dockerfile: Dockerfile
+ args:
+ APP_NAME: test-lib
+ ENV: daily
+ image: test-lib:latest
+ ports:
+ - "8005:8005"
+ depends_on:
+ - mysql
+ - redis
+ environment:
+ <<: *common-variables
+ # db
+ db_url: mysql+aiomysql://${db_user}:{db_password}@mysql:3306/test-lib
+ # redis
+ redis_url: redis://:${redis_password}@redis:6379/10
+ # app
+ tone_host: http://${server_ip}:8080/
+ tone_token: tone_token
+ tone_user_name: tone_user_name
+ main_domain: http://${server_ip}:8005
+ oss_url: http://${server_ip}:8005
+```
+#### e.重启服务
+```shell
+docker-compose -f ~/tone/docker-compose.yaml up --build -d
+```
+## 7. 独立部署 FAQ
+https://tone.openanolis.cn/help_doc/12
\ No newline at end of file
diff --git "a/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/zzzz.md" "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/zzzz.md"
new file mode 100644
index 0000000000000000000000000000000000000000..bce7de8006c232d78a6c8052190ff0a3a60a8fa0
--- /dev/null
+++ "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/zzzz.md"
@@ -0,0 +1,73 @@
+*斜体文字*
+
+_斜体文字_
+
+**粗体文字**
+
+__粗体文字__
+
+***粗斜体文字***
+
+___粗斜体文字___
+
+***
+* * *
+******
+- - -
+------
+
+~~删除线~~
+
+带下划线文本
+
+# 一级标题
+
+## 二级标题
+
+### 三级标题
+
+#### 四级标题
+
+##### 五级标题
+
+###### 六级标题
+[链接]（http://a.com）
+
+> 引用
+* 第一项
+* 第二项
+* 第三项
+
++ 第一项
++ 第二项
++ 第三项
+
+- 第一项
+- 第二项
+- 第三项
+1. 第一项
+2. 第二项
+3. 第三项
+
+1. 第一项：
+ - 第一项嵌套的第一个元素
+ - 第一项嵌套的第二个元素
+2. 第二项：
+ - 第二项嵌套的第一个元素
+ - 第二项嵌套的第二个元素
+水平线：
+
+---
+带反引号的“内联代码”
+```
+# 代码块
+print '3 个反引号或'
+print '缩进 4 个空格'
+```
+
+> 区块引用
+> Markdown教程
+> 学的不仅是技术更是梦想
+
+
+SDFGSDFGSDFGSDFG
\ No newline at end of file
diff --git "a/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/\347\224\250\346\210\267\350\201\206\345\220\254/test.md" "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/\347\224\250\346\210\267\350\201\206\345\220\254/test.md"
new file mode 100644
index 0000000000000000000000000000000000000000..b09df7d02fee342106c45e78485a992609d67bdb
--- /dev/null
+++ "b/sig/T-One-copy3/content/\347\224\250\346\210\267\346\214\207\345\215\227/\347\224\250\346\210\267\350\201\206\345\220\254/test.md"
@@ -0,0 +1,70 @@
+# 一级标题
+## 二级标题
+### 三级标题
+**粗体文本**
+
+__cuti__
+
+*斜体文本*
+
+_xieti_
+
+下划线
+
+~~删除线~~
+
+上标：Xy
+
+下标：An
+
+> 引用文本
+- 无序列表项1
+ - 第二层
+- 无序列表项2
+* * *
+1. 有序列表项1
+2. 有序列表项2
+---
+[链接文本](https://gitee.com/suli01/community/edit/master/sig/T-One/content/%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97/%E7%94%A8%E6%88%B7%E8%81%86%E5%90%AC/test.md)
+
+链接名称
+
+'''python
+def hello_world():
+ print("Hello, world!")
+
+
+
+| 列1 | 列2 | 列3 |
+| --- | --- | --- |
+| 单元格1 | 单元格2 | 单元格3 |
+| 单元格4 | 单元格5 | 单元格6 |
+
+
+| 左对齐 | 居中对齐 | 右对齐 |
+|:-----|:------:|------:|
+| 文本 | 文本 | 文本 |
+
+
+
+
+
+ | 值班人员 |
+ 星期一 |
+ 星期二 |
+ 星期三 |
+
+
+ | 张三 |
+ 李四 |
+ 王五 |
+
+
+
+- [ ] ：待完成事项
+
+- [x] ：已完成事项
+
+
+
+