小编Saf*_*med的帖子

我基本上需要一些帮助来解释/确认一些实验结果.

基础理论

关于DVFS的论文中表达的一个常见想法是执行时间具有片上和片外组件.执行时间的片上组件与CPU频率成线性关系,而片外组件保持不受影响.

因此,对于CPU绑定应用程序,CPU频率和指令退出率之间存在线性关系.另一方面,对于经常错过高速缓存并且必须频繁访问DRAM的内存绑定应用程序,关系应该是仿射的(一个不仅是另一个的倍数,还必须添加常量).

实验

我正在做实验,看看CPU频率如何在不同的内存限制水平下影响指令退出率和执行时间.

我在C中编写了一个遍历链表的测试应用程序.我有效地创建了一个链表,其各个节点的大小等于缓存行的大小(64字节).我分配了大量内存,这是缓存行大小的倍数.

链表是循环的,使得最后一个元素链接到第一个元素.此外,该链表随机遍历分配的内存中的高速缓存行大小的块.访问分配的内存中的每个缓存行大小的块,并且不会多次访问任何块.

由于随机遍历,我认为硬件不应该使用任何预取.基本上,通过遍历列表,您有一系列内存访问,没有步幅模式,没有时间局部性,也没有空间局部性.此外,因为这是一个链接列表,所以只有一个内存访问才能在前一个内存访问完成之前开始.因此,存储器访问不应该是可并行化的.

当分配的内存量足够小时,除了初始预热之外,您应该没有缓存未命中.在这种情况下,工作负载实际上受CPU限制,并且指令退出率与CPU频率非常干净地扩展.

当分配的内存量足够大(大于LLC)时,您应该错过缓存.工作负载受内存限制,指令退出率也不应随CPU频率而扩展.

基本的实验设置与此处描述的类似:" 实际CPU频率与Linux报告的CPU频率"cpufreq"子系统 ".

上述应用程序重复运行一段时间.在持续时间的开始和结束时,对硬件性能计数器进行采样,以确定在该持续时间内退出的指令数.也测量持续时间的长度.平均指令退休率是以这两个值之间的比率来衡量的.

使用Linux中的"用户空间"CPU频率调控器在所有可能的CPU频率设置中重复此实验.此外,如上所述,对CPU绑定的情况和存储器绑定的情况重复该实验.

结果

下面两个图分别显示了CPU绑定情况和内存绑定情况的结果.在x轴上,CPU时钟频率以GHz为单位指定.在y轴上,指令退出率以(1/ns)指定.

放置标记物以重复上述实验.该行显示如果指令退出率以与CPU频率相同的速率增加并通过最低频率标记,结果将是什么.

CPU绑定案例的结果.

内存限制案例的结果.

结果对CPU绑定的情况有意义,但对于内存限制的情况则没有那么多.内存限制的所有标记都低于预期的行,因为指令退出率不应该以与内存绑定应用程序的CPU频率相同的速率增加.标记似乎落在直线上,这也是预期的.

但是,随着CPU频率的变化,指令退出率似乎会发生阶跃变化.

题

是什么导致指令退休率的步骤变化？我能想到的唯一解释是内存控制器以某种方式通过内存请求速率的变化来改变内存的速度和功耗.(随着指令退出率的增加,内存请求的速率也应该增加.)这是正确的解释吗？

我正在使用共享源代码构建一组Linux内核模块.根据我的理解,Makefile必须命名为"Makefile",所以我必须使用相同的Makefile来构建两个不同的模块.如何在同一个Makefile中使用相同的源代码构建两个不同的模块,但是有两个不同的构建选项？

例如,我的模块称为module1和module2.所以我有以下行来定义它们:

obj-m := module1.o module2.o

在其他文件中,module1和module2都需要使用相同的源文件code.c,但使用不同的构建选项构建.例如,Makefile包含以下行:

module1-objs = module1_code.o other_code.o
module2-objs = module2_code.o other_code.o

我希望module1_code.o并module2_code.o从code.c构建,但具有不同的选项.具体来说,我想要一个module1_code.o宏定义的宏-DPREPROCEFFOR_FLAG=1,并module2_code.o建立没有宏.

根据我的理解,Linux中使用的Makefile系统隐含地推断出对于名为"code.o"的目标文件,源文件被称为"code.c",那么我该如何实现呢？有可能吗？有一个更好的方法吗？

是否存在可供内核模块使用的单调时钟源,该内核模块可以附加到线程,只有在关联的线程运行时才会增加？

我正在寻找能像perfAPI 一样工作的东西,除了测量迄今为止所消耗的CPU时间总量(以纳秒为单位)而不是测量周期或指令.

在用户空间中,您可以使用此clock_gettime功能librt指定CLOCK_PROCESS_CPUTIME_ID时钟类型以获取上述行为.查看源代码clock_gettime,该函数调用来自pthread库的另一个函数调用__pthread_clock_gettime.

我正在寻找类似的东西,可以从内核模块在Linux内核中设置并附加到任务,给定指向task_struct与任务相关联的指针.