目前要测试一段驱动程序在ARM和X86不同款型CPU上的性能；需求是可以在任意一段代码前后进行打点N次，然后show出cycle的平均开销值（算平均值避免波动的影响）；
关键点为：（1）cpu上获取cycle值的方法； （2）设计结构体能够存储不同cpu core的不同事件的多次cycle开销值；
一：CPU的打点方法：
耗时 = 周期计数/CPU主频速率（Hz）；
X86：
static __inline__ unsigned long long rdtsc(void) { unsigned hi, lo; __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi)); return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 ); }
ARM：
static inline u64 arch_counter_get_cntpct(void) { u64 cval; asm volatile("mrs %0, PMCCNTR_EL0" : "+r"(cval)); return cval; }
在arm机上做测试：
#include <stdio.h> #include <stdint.h> #include <stdlib.h> static uint64_t get_cycle() { uint64_t cycle; //asm volatile("mrs %0, cntvct_el0" : "=r" (cycle)); asm volatile("mrs %0, pmccntr_el0" : "=r" (cycle)); return cycle; } int main() { uint64_t c1, c2; c1 = get_cycle(); usleep(1000000); c2 = get_cycle(); printf("cycles per second: %lu\n", c2 - c1); return 0; }
测试结果如下：
问题记录：
编译运行时会报Ilegal Instruction错误，原因为要在用户态获取pmccntr寄存器的值，需要先在内核态打开pmu的使能开关；
这里解决办法是通过插入pmu_el0_cycle_counter.ko解决；ko源码来源：https://github.com/jerinjacobk/armv8_pmu_cycle_counter_el0
二：优化代码：
（1）考虑结果buffer的形式：
需要一个全局变量来存储获取的cycle值；假设当前CPU有m个core、每个core需要记录n个事件的cycle，每次记录取1000次cycle的平均值；
相比于以下这种声明全局的方法
u64 cycle_count[m][n][1000]；
struct single_cycle{ u64 single_t[1000]; }; struct event_count{ struct single_cycle event_t[n]; }; struct cycle_count{ struct event_count cycle_t[m]; };
使用cycle_count结构体的方法显然更为高效；避免了大量寻址访问的开销；
（2）考虑函数调用开销： 由于是在一个while循环中加入计算cycle的打点函数，尽量使用inline内联函数声明。避免的不断的函数调用带来的栈内存开销。
关于内联函数：https://blog.csdn.net/zqixiao_09/article/details/50877383
（3）多核多线程场景下存在的内存和cache问题：
struct cycle_count中的m代表了多个cpu core，用来在内存中存储不同cpu core 的cycle 统计值；
当前的场景是多核多线程，共享L3 cache，cacheline大小为128K； 因此存在一种异常场景，在线程A中cpu将值通过cache刷到内存中时，是按照128K的倍数进行刷新，如果此时内存中的buffer小于
128K或非128K的倍数，通过缓存刷入的值将会覆盖掉其他内存区域的值，产生conflict；
因此，用来保存cycle value的全局应该是128K的倍数，将single_cycle中的single_t[1000]定义为single_t[1024]，以解决此问题；
扩展：进一步cache的相关知识；
一：以下为阅读《深入浅出dpdk》的cache和内存一章的总结
补充ing；
二：cache一致性的问题及解决方法：
转自：https://blog.csdn.net/ds1130071727/article/details/82629165
CPU的读/写（以及取指令）单元正常情况下甚至都不能直接访问内存——这是物理结构决定的；CPU都没有管脚直接连到内存。相反，CPU和一级缓存（L1 Cache）通讯，而一级缓存才能和内存通讯。大约二十年前，一级缓存可以直接和内存传输数据。如今，更多级别的缓存加入到设计中，一级缓存已经不能直接和内存通讯了，它和二级缓存通讯——而二级缓存才能和内存通讯。或者还可能有三级缓存。你明白这个意思就行。
缓存是分“段”（line）的，一个段对应一块存储空间，大小是32（较早的ARM、90年代/2000年代早期的x86和PowerPC）、64（较新的ARM和x86）或128（较新的Power ISA机器）字节。每个缓存段知道自己对应什么范围的物理内存地址，并且在本文中，我不打算区分物理上的缓存段和它所代表的内存，这听起来有点草率，但是为了方便起见，还是请熟悉这种提法。具体地说，当我提到“缓存段”的时候，我就是指一段和缓存大小对齐的内存，不关心里面的内容是否真正被缓存进去（就是说保存在任何级别的缓存中）了。
当CPU看到一条读内存的指令时，它会把内存地址传递给一级数据缓存（或可戏称为L1D$，因为英语中“缓存（cache）”和“现金（cash）”的发音相同）。一级数据缓存会检查它是否有这个内存地址对应的缓存段。如果有，它会把整个缓存段从内存（或者从更高一级的缓存，如果有的话）中加载进来。是的，一次加载整个缓存段，这是基于这样一个假设：内存访问倾向于本地化（localized），如果我们当前需要某个地址的数据，那么很可能我们马上要访问它的邻近地址。一旦缓存段被加载到缓存中，读指令就可以正常进行读取。
如果我们只处理读操作，那么事情会很简单，因为所有级别的缓存都遵守以下规律，我称之为：
基本定律：在任意时刻，任意级别缓存中的缓存段的内容，等同于它对应的内存中的内容。
一旦我们允许写操作，事情就变得复杂一点了。这里有两种基本的写模式：直写（write-through）和回写（write-back）。直写更简单一点：我们透过本级缓存，直接把数据写到下一级缓存（或直接到内存）中，如果对应的段被缓存了，我们同时更新缓存中的内容（甚至直接丢弃），就这么简单。这也遵守前面的定律：缓存中的段永远和它对应的内存内容匹配。
回写模式就有点复杂了。缓存不会立即把写操作传递到下一级，而是仅修改本级缓存中的数据，并且把对应的缓存段标记为“脏”段。脏段会触发回写，也就是把里面的内容写到对应的内存或下一级缓存中。回写后，脏段又变“干净”了。当一个脏段被丢弃的时候，总是先要进行一次回写。
回写定律：当所有的脏段被回写后，任意级别缓存中的缓存段的内容，等同于它对应的内存中的内容。
换句话说，回写模式的定律中，我们去掉了“在任意时刻”这个修饰语，代之以弱化一点的条件：要么缓存段的内容和内存一致（如果缓存段是干净的话），要么缓存段中的内容最终要回写到内存中（对于脏缓存段来说）。
直接模式更简单，但是回写模式有它的优势：它能过滤掉对同一地址的反复写操作，并且，如果大多数缓存段都在回写模式下工作，那么系统经常可以一下子写一大片内存，而不是分成小块来写，回写的效率更高。
有些（大多数是比较老的）CPU只使用直写模式，有些只使用回写模式，还有一些，一级缓存使用直写而二级缓存使用回写。这样做虽然在一级和二级缓存之间产生了不必要的数据流量，但二级缓存和更低级缓存或内存之间依然保留了回写的优势。我想说的是，这里涉及到一系列的取舍问题，且不同的设计有不同的解决方案。没有人规定各级缓存的大小必须一致。举个例子，我们会看到有CPU的一级缓存是32字节，而二级缓存却有128字节。
为了简化问题，我省略了一些内容：缓存关联性（cache associativity），缓存组（cache sets），使用分配写（write-allocate）还是非分配写（上面我描述的直写是和分配写相结合的，而回写是和非分配写相结合的），非对齐的访问（unaligned access），基于虚拟地址的缓存。如果你感兴趣，所有这些内容都可以去查查资料，但我不准备在这里讲了。
一致性协议（Coherency protocols）
【核心问题】只要系统只有一个CPU核在工作，一切都没问题。如果有多个核，每个核又都有自己的缓存，那么我们就遇到问题了：如果某个CPU缓存段中对应的内存内容被另外一个CPU偷偷改了，会发生什么？
好吧，答案很简单：什么也不会发生。这很糟糕。因为如果一个CPU缓存了某块内存，那么在其他CPU修改这块内存的时候，我们希望得到通知。我们拥有多组缓存的时候，真的需要它们保持同步。或者说，系统的内存在各个CPU之间无法做到与生俱来的同步，我们实际上是需要一个大家都能遵守的方法来达到同步的目的。
注意，这个问题的根源是我们拥有多组缓存，而不是多个CPU核。我们也可以这样解决问题，让多个CPU核共用一组缓存：也就是说只有一块一级缓存，所有处理器都必须共用它。在每一个指令周期，只有一个幸运的CPU能通过一级缓存做内存操作，运行它的指令。
这本身没问题。唯一的问题就是太慢了，因为这下处理器的时间都花在排队等待使用一级缓存了（并且处理器会做大量的这种操作，至少每个读写指令都要做一次）。我指出这一点是因为它表明了问题不是由多核引起的，而是由多缓存引起的。我们知道了只有一组缓存也能工作，只是太慢了，接下来最好就是能做到：使用多组缓存，但使它们的行为看起来就像只有一组缓存那样。缓存一致性协议就是为了做到这一点而设计的。就像名称所暗示的那样，这类协议就是要使多组缓存的内容保持一致。
缓存一致性协议有多种，但是你日常处理的大多数计算机设备使用的都属于“窥探（snooping）”协议，这也是我这里要讲的。（还有一种叫“基于目录的（directory-based）”协议，这种协议的延迟性较大，但是在拥有很多个处理器的系统中，它有更好的可扩展性。）
“窥探”背后的基本思想是，所有内存传输都发生在一条共享的总线上，而所有的处理器都能看到这条总线：缓存本身是独立的，但是内存是共享资源，所有的内存访问都要经过仲裁（arbitrate）：同一个指令周期中，只有一个缓存可以读写内存。窥探协议的思想是，缓存不仅仅在做内存传输的时候才和总线打交道，而是不停地在窥探总线上发生的数据交换，跟踪其他缓存在做什么。所以当一个缓存代表它所属的处理器去读写内存时，其他处理器都会得到通知，它们以此来使自己的缓存保持同步。只要某个处理器一写内存，其他处理器马上就知道这块内存在它们自己的缓存中对应的段已经失效。
在直写模式下，这是很直接的，因为写操作一旦发生，它的效果马上会被“公布”出去。但是如果混着回写模式，就有问题了。因为有可能在写指令执行过后很久，数据才会被真正回写到物理内存中——在这段时间内，其他处理器的缓存也可能会傻乎乎地去写同一块内存地址，导致冲突。在回写模型中，简单把内存写操作的信息广播给其他处理器是不够的，我们需要做的是，在修改本地缓存之前，就要告知其他处理器。搞懂了细节，就找到了处理回写模式这个问题的最简单方案，我们通常叫做MESI协议（译者注：MESI是Modified、Exclusive、Shared、Invalid的首字母缩写，代表四种缓存状态，下面的译文中可能会以单个字母指代相应的状态）。
MESI以及衍生协议
本节叫做“MESI以及衍生协议”，是因为MESI衍生了一系列紧密相关的一致性协议。我们先从原生的MESI协议开始：MESI是四种缓存段状态的首字母缩写，任何多核系统中的缓存段都处于这四种状态之一。我将以相反的顺序逐个讲解，因为这个顺序更合理：
失效（Invalid）缓存段，要么已经不在缓存中，要么它的内容已经过时。为了达到缓存的目的，这种状态的段将会被忽略。一旦缓存段被标记为失效，那效果就等同于它从来没被加载到缓存中。
共享（Shared）缓存段，它是和主内存内容保持一致的一份拷贝，在这种状态下的缓存段只能被读取，不能被写入。多组缓存可以同时拥有针对同一内存地址的共享缓存段，这就是名称的由来。
独占（Exclusive）缓存段，和S状态一样，也是和主内存内容保持一致的一份拷贝。区别在于，如果一个处理器持有了某个E状态的缓存段，那其他处理器就不能同时持有它，所以叫“独占”。这意味着，如果其他处理器原本也持有同一缓存段，那么它会马上变成“失效”状态。
已修改（Modified）缓存段，属于脏段，它们已经被所属的处理器修改了。如果一个段处于已修改状态，那么它在其他处理器缓存中的拷贝马上会变成失效状态，这个规律和E状态一样。此外，已修改缓存段如果被丢弃或标记为失效，那么先要把它的内容回写到内存中——这和回写模式下常规的脏段处理方式一样。
如果把以上这些状态和单核系统中回写模式的缓存做对比，你会发现I、S和M状态已经有对应的概念：失效/未载入、干净以及脏的缓存段。所以这里的新知识只有E状态，代表独占式访问。这个状态解决了“在我们开始修改某块内存之前，我们需要告诉其他处理器”这一问题：只有当缓存段处于E或M状态时，处理器才能去写它，也就是说只有这两种状态下，处理器是独占这个缓存段的。当处理器想写某个缓存段时，如果它没有独占权，它必须先发送一条“我要独占权”的请求给总线，这会通知其他处理器，把它们拥有的同一缓存段的拷贝失效（如果它们有的话）。只有在获得独占权后，处理器才能开始修改数据——并且此时，这个处理器知道，这个缓存段只有一份拷贝，在我自己的缓存里，所以不会有任何冲突。
反之，如果有其他处理器想读取这个缓存段（我们马上能知道，因为我们一直在窥探总线），独占或已修改的缓存段必须先回到“共享”状态。如果是已修改的缓存段，那么还要先把内容回写到内存中。
MESI协议是一个合适的状态机，既能处理来自本地处理器的请求，也能把信息广播到总线上。我不打算讲更多关于状态图的细节以及不同的状态转换类型。如果你感兴趣的话，可以在关于硬件架构的书中找到更多的深度内容，但对于本文来说，讲这些东西有点过了。作为一个软件开发者，你只要理解以下两点，就大有可为：
第一，在多核系统中，读取某个缓存段，实际上会牵涉到和其他处理器的通讯，并且可能导致它们发生内存传输。写某个缓存段需要多个步骤：在你写任何东西之前，你首先要获得独占权，以及所请求的缓存段的当前内容的拷贝（所谓的“带权限获取的读（Read For Ownership）”请求）。
第二，尽管我们为了一致性问题做了额外的工作，但是最终结果还是非常有保证的。即它遵守以下定理，我称之为：
MESI定律：在所有的脏缓存段（M状态）被回写后，任意缓存级别的所有缓存段中的内容，和它们对应的内存中的内容一致。此外，在任意时刻，当某个位置的内存被一个处理器加载入独占缓存段时（E状态），那它就不会再出现在其他任何处理器的缓存中。
注意，这其实就是我们已经讲过的回写定律加上独占规则而已。我认为MESI协议或多核系统的存在根本没有弱化我们现有的内存模型；
