[IPM] (http://ipm-hpc.sourceforge.net/)(Integrated Performance Monitoring)是用于MPI性能评测的一套软件库，声称可以收集MPI函数运行时间、通信拓扑、通信量统计、能耗统计等等功能。
这个问题解决了我在阅读IPM源码的时候发现的MPI_开头和PMPI_开头的函数的区别和关系的疑惑，同时也解决了我对于IPM运行原理的疑惑。
主要原理就是通过使用加了debug逻辑的IPM库代替原始MPI函数，达到既不影响原有程序执行，又能收集性能数据的目的。
达成目的的方法有两种，一是经典的显示链接，在编译时就指定要使用IPM版的MPI函数实现；二是利用动态库的骚操作，利用系统环境变量“劫持”运行时程序要调用的MPI实现，通过LD_PRELOAD的优先级实现。
之前因为要用到某些IPv6的网站，就把网线从不支持IPv6的路由器上拔下来，直接插到光猫上，拨号上网。
结果问题就来了。最近在收集3A大作，每次挂上bt大约一个小时左右，系统就会直接卡死。没错，不是自动重启，也没有蓝屏，整块屏幕就保持卡死前最后一刻的状态，硬盘灯也不闪。这导致，上百G的文件好不容易花上快半个小时校验完，还没下个多少，又得重新校验。这个问题连着出了四五次，使我提高了对这个问题的重视程度。
后来左思右想，想不出哪里出了问题，打算做出硬件出现了暗伤的结论。偶然想到唯一做出的硬件变更就是换了网络连接方式，打算死马当活马医，把网线插回路由器试试（这样电脑就没了IPv6，同时也不需要自己拨号了）。
结果。。
很快啊，啪的一下就好了，bt连着用了近10小时都没出再出现这个问题。
于是得出结论：Windows 8 + P8B75-V + bt + 拨号 = 大概率卡死。
至于为什么是这样，我也不知道
===============================
后记
尝试了一下，如果把下载速度限制在一个合适的范围，好像就不会翻车，用60M的宽带，限制在5000K下载就没问题。
接上文换硬盘。换完硬盘之后，顺手把之前装的Windows 8一起复制过来了，当作大号的PE使用，甚至还能放办公，打游戏。结果修复完引导（EasyBCD选择在当前系统下的盘符，不会修改系统挂载的盘符），一开机，发现锁屏界面是有的，但是壁纸不见了。输入密码登录，卡在“正在准备Windows”，即使不登录，想使用系统关机键关机，程序都会报错，连关机按钮都见不到。
然后在网上找，听到别人说可能是系统配置的问题，有不少人在系统备份前会主动将系统设置到sysprep模式下，在该模式中，系统会检测当前硬件，且根据现有的硬件生成合适的配置文件。然而，我遇到了两个问题：第一，该模式只能在系统内部进入，所以需要先把硬件配置完全改回原来的样子才能启动；第二，这种方法不一定成功，且失败后果很严重，尤其是当作为双系统安装在非C盘的时候，之前的配置文件会全部丢掉，无法回到原样。因为不愿浪费更多的时间在那块SMR硬盘上，只好作罢。
后来开始考虑是不是可能是根分区（借用Linux术语，这里指Windows系统所在分区）挂载出错的问题，因为Linux的GRUB配置出错的时候也会这样，系统一部分功能是正常的（因为已经加载到了内存），但是剩下的完全不可用。
然后就去查了一下Windows存不存在类似于盘符到分区UUID的缓存表一类的，结果还真找到了（https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/restore-system-boot-drive-letter）。
经过测试，解决这个问题的方法是，在任意一个可以在当前硬件配置条件下启动的系统中（比如新装的系统或者迁移的Windows 10），挂载Windows 8的SYSTEM注册表，修改其中对应的每个分区在HKLM\SYSTEM\MountedDevices中的那串二进制标识，从当前系统的值直接全选，对应覆盖复制过去就行了。
然而Windows 10可以自动在新硬件环境上自动适配分区标识，猜测可能的原因是，这个功能在Windows 10才被添加进系统的启动流程中，而Windows 8开发的时候并没有。（然而Win8能自动适配外围设备已经很强了）
起因在于之前使用全键盘进行Linux操作的时候，无意间碰到了Page Up按键，开启了奇妙体验。把一条命令打到一半，然后按Page Up/Page Down就可以匹配历史记录，实在是太舒服了。
然而在使用Ubuntu的时候，突然发现就没有这个功能了，StackOverflow一查，才发现原来是需要手动配置的。
修改/etc/inputrc或者~/.inputrc，这么修改一下，就能把这个功能和Page Up/Page Down按键绑定：
$if mode=emacs
"\e[5~": history-search-backward
"\e[6~": history-search-forward
$endifhttps://stackoverflow.com/questions/46667659/kubernetes-cannot-access-nodeport-from-other-machines
本来第一次配置集群的时候，是可以在局域网内访问的，之后关机重启，遇到DiskPressure这个Taint“污点（标记）”的时候，重新配置了一次集群（即kubeadm reset和kubeadm init），然后以为是服务没跑起来，测试以后发现只能在本机访问了。
nmap扫了一遍端口，目标端口显示的不是closed，而是filtered，然后也隐隐猜测和防火墙有关，万万没想到，原因正是出在iptables上。而后了解到，firewalld和iptables是两个不同的Linux防火墙工具，有着各自独立的规则。因而在配置Kubernetes时禁用了firewalld之后，iptables还是在工作的。而NodePort的访问，需要进行流量转发。
简单粗暴的解决方式（非生产环境）：
iptables -A FORWARD -j ACCEPT不过这个地方我有点没想明白：kube-proxy可以将Pod内的端口映射到主机端口的监听上，而在Linux中，默认的端口监听是监听在所有可用的interface网络接口上的，监听特定的网络接口是需要编程显式声明的，理论上不会需要进行不同网络接口间的流量转发。