该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
在吧里很久没冒泡了，不过之前在3A2000上有发现一些严重影响性能的地方，不清楚龙芯的开发人员有没有注意到，所以想想还是贴出来吧。性能研究工具是perf，perf record、perf top什么的。
1. 不对齐load/store陷入内核模拟，严重影响性能
去年年底测试AMD64虚拟机，以下是perf report
37.36% qemu-system-x86 qemu-system-x86_64 [.] tcg_qemu_tb_exec
33.37% qemu-system-x86 [kernel.vmlinux] [k] handle_adel
9.01% qemu-system-x86 [kernel.vmlinux] [k] do_ade
2.55% qemu-system-x86 [kernel.vmlinux] [k] ret_from_exception
1.66% qemu-system-x86 [kernel.vmlinux] [k] signalfd_pol
使用的是没打补丁的qemu 2.6.0，因为MIPS TCG有问题，所以只开了解释模式，即便如此非对齐load/store也吃掉了42%的性能！另外Rust编译等情景下也时不时会出现handle_adel炸 裂的情况。
建议在硬件层面优化非对齐访存操作，实际上不少RISC架构都后期加入了非对齐访存的能力，因为指望开发者们都想着对齐有点不切实际，总不能一直跟在不会对齐的人背后擦屁股吧
2. 优化VDSO，给gettimeofday、clock_gettime等函数进行龙芯优化
很多应用会在事件循环等情形下疯狂取当前时间，很不幸MIPS架构上这些系统调用没有像x86下一样直接在用户态实现，于是每个此类系统调用都会进出一次内核模式。此问题去年刚开始玩就注意到了，不过哪个应用不记得了，现在有没有修好也不知道。实现应该比较简单，直接照着x86的思路改mips就行了
3. 优化TLS访问
不知为何取TLS地址的rdhwr在micro-benchmark里表现还算出色，但一到正常应用里就炸 裂，perf top里能飙升到瓶颈第一位！同样忘记了哪个应用可以重现。。。不清楚底层这指令实现怎么回事，难道跟分支预测有关？
4. 分支预测
之前也提到过，分支预测是龙芯与x86阵营主要差距之一，不少micro-benchmark里x86 <1%的分支预测失误率到了龙芯就个位数甚至十位数！不过这一方面我自己也不熟悉，而且只能靠硬件优化，还是少说一点好
5. 编译器适配
LoongISA指令很多，很好，要用起来！很久之前2E/2F的时候有往上游送过很多补丁，支持龙芯特有指令啦，支持龙芯SIMD实现啦(其实跟MMX几乎一样)，但近几年完全看不到了。私以为向量指令是一定要追求上游支持的，因为现在的编译器都会自动向量化了，还是一开始那句话，不能一直由龙芯的人跟在不懂MIPS的人背后擦屁股。还有其他一些Loongnix的代码，其实测试个半年之后也可以往上游推了。否则总是自己维护fork，龙芯人又少，版本绝对跟不上的。官方的Linux支持版本号多久没升级了？gcc？binutils？qemu？ffmpeg？
6. 莫名其妙的全系统冻结
真心没时间移植新版本内核了，所以用的还是之前做的4.8内核。开机几分钟不动就会死 掉，后台起一个cyclictest不断产生软中断会好一些，就这样连续开机大概12小时还是会死，一直没有时间调试具体原因。这是为什么呢？
