ARM架构下操作系统页的大小设定问题？

暂时没有调整过，仍然是用的4kb模式。

https://gitee.com/openeuler/kernel/issues/I4HDHZ

决策诉求

决策点1：openEuler 22.03 LTS 是否默认采用 4K 页表

决策点2：openEuler 22.03 LTS 是否单独出64K页表的 kernel 包

kernel sig 交流群讨论

@Jason: 64K，不管是服务器还是高性能嵌入式控制器，未来都需要更大的页大小。之前做过一种磁盘阵列的控制器，发现 Pagesize 改成64K，性能提升很大。对 IOT 设备，4K 很好。但是对于高性能设备，比如企业存储系统或多CPU的HPC，那肯定是64K无敌。

@驴肉火烧: 64K 会有兼容性问题，需要大页就自己使用大页即可。

@李俊良: 社区确实还是得照顾生态。

@Leo: 赞同，不建议默认 64K。

@雨轻: 在一些性能测试，4K差的太远了，建议64K

@杨洋: 64K 也会增加内存总占用量。

@康师傅: 有些程序在64K内存页下无法执行。有些程序使用系统的 PAGESIZE 参数，然后按照4k进行内存对齐操作，如果变成64K，这个计算就会出错，导致程序执行错误。有太多应用程序都是按照4k内存页来编写代码的。全部改掉不太现实。

@Leo: 据我了解，arm64 处理器soc在硬件设计时，片内外设控制器的寄存器地址分部好多都是做的4k对齐，还有一些pci设备 BAR空间可能会按4k对齐，如果pagesize是64K的话，可能用户态驱动用不了。当然64K效率更高，但是牺牲了内存资源，力度越大，碎片越多吧。至少4K跑着都没问题，然后需要用大块内存时，看一看用大页。或者自己重新编译64k 的内核。

@jiao: 有的应用的 4k，64k 运行不起来。没有统计过4k 64k 场景占比。

@肖磊: 64K 的话，默认 arm 的本上起虚拟机跑欧拉都有问题，还是4k对开发者友好一些。

@Coly: pagesize 4k 挺好。咱们的配置可以看一下 redhat 和 suse 的arm配置，尽量和他们一样。再这样也有利于对一些重要的企业软件做兼容性认证。SAP Hana 用的是透明大页，内核还是4K，用户态透明大页。（RHEL 9 使用的是4K）那看来还是4K好。

@王丹: 4K 对应用、驱动 友好，对 TLB 不友好。特别的，对 intel 家的一些网卡芯片来说（如E810），非4K page 会导致 RDMA 功能跑不起来。有办法测试出更多级差别及TLB miss 带来的性能损失吗？除了这两点，其他角度看 4K 更好。

@阴进涛: 还是选 4k 好一些。

@王丹: 看起来各方面都遇到过不少64K相关的问题，想软件生态妥协，遇到性能问题请用 HugePages。 如此的话，是应该选择 4K。