为了调试一个功能，在一个内核模块中，增加了一个全局变量，用来统计自有skb池的申请情况。
因为是临时增加，所以没有考虑性能，一开始只是一个fail的统计，数量不多，也不太考虑是否有计数丢失的情况，毕竟那个卖火车票的例子已经让很多人知道了并发导致的计数丢失。
因为只是一个简单统计，这样做无可厚非。
后来有人维护的时候，增加了一个success的统计，结果发现增加该变量前后cpu占用增加了一个点。为了排除是伪共享的行为，我将两个变量中间增加了一些reserve的空间，结果还是如此。去掉success统计，立刻恢复。一个简单的计数居然导致如此的性能变化，只能祭出倚天剑了，perf上马。
根据perf stat 的统计，我发现 cache-misses这一行有明显的增长，
最后排查的原因就是，由于是一个多核的设备，每个cpu都会对这个变量进行++，也就是这个变量是一个热点，当A cpu对其++的时候，根据mesi协议，显然会发送让其他cpu对这个变量进行读缓存失效，并且还需要等待其他cpu的回复的最新的缓存值。虽然这个过程是由硬件实现的，但对性能的影响却是显而易见的。
所以将这个统计改成percpu变量，然后需要show的时候，将各个cpu相加起来就ok。牺牲了部分准确性，但提高了性能，因为性能这个词，本来就是一种权衡，不管是用时间换空间还是空间换时间。
所以多核并发，针对统计类的实现，最好实现成percpu的。这个就是经典的并行拆分思路。
ps：
推荐对并发编程感兴趣的童鞋，可以参考老谢和鲁阳翻译的《深入理解并行编程》。