Buildroot:Debugging, profiling and benchmark(1)
1 blktrace
blktrace 是一个 Linux 内核工具,用于跟踪和分析块设备(如硬盘、固态硬盘、USB 存储设备等)的 I/O 请求。它可以帮助用户理解操作系统如何与块设备交互,以及 I/O 请求在系统中的流动情况。这对于性能分析、故障排除和存储系统优化非常有用。
参考《Linux IO性能分析blktrace/blk跟踪器 - ArnoldLu - 博客园 (cnblogs.com)》。
2 bonnie++
Bonnie++ 是一个开源的磁盘基准测试工具,用于评估文件系统的读写性能。它由 Matt Domsch 编写,最初是为了测试 Linux 内核的 I/O 调度器性能而开发的。Bonnie++ 可以提供关于磁盘 I/O 性能的详细信息,包括随机读写、顺序读写、文件创建、删除和重命名等操作的性能。
3 cache-calibrator
3.1 cache-calibrator测试介绍
cache-calibrator是一个用于测量 CPU Cache和 TLB(Translation Lookaside Buffer)性能的工具。
cache_calibrator 1000 16M file Calibrator v0.9e (by Stefan.Manegold@cwi.nl, http://www.cwi.nl/~manegold/) 84643010 140735414546448 4096 16 84643fff 140735414550527 4096 4095 84644000 140735414550528 4096 0 MINTIME = 10000 analyzing cache throughput... range stride spots brutto- netto-time 20971520 8 2621440 18624 582 analyzing cache latency... range stride spots brutto- netto-time 20971520 8 2621440 172032 672 analyzing TLB latency... range stride spots brutto- netto-time 13107200 5120 2560 41361 41361 CPU loop + L1 access: 4.39 ns = 4 cy ( delay: 1.42 ns = 1 cy ) caches: level size linesize miss-latency replace-time 1 512 KB 4096 bytes 477.79 ns = 478 cy 478.30 ns = 478 cy TLBs: level #entries pagesize miss-latency 1 80 5 KB 5.14 ns = 5 cy
以下是 Cache Calibrator 输出的解析:
1. 内存分配信息:
- 输出的前三行显示了内存分配的详细信息,包括起始地址、结束地址、行大小和步长。
2. MINTIME:
- MINTIME = 10000 表示为了确保测量的准确性,任何小于 10000 时钟周期的结果都将被忽略。
3. Cache吞吐量分析:
- range:测试的内存范围。
- stride:步长,即每次访问之间的字节数。
- spots:访问的内存位置数量。
- brutto-time:总时间,包括缓存未命中和替换时间。
- netto-time:净时间,排除了缓存未命中和替换时间。
例如,20971520 8 2621440 18624 582 表示在 20971520 字节的范围内,以 8 字节的步长访问了 2621440 个内存位置,总时间为 18624 时钟周期,净时间为 582 时钟周期。
4. Cache延迟分析:
- 类似于吞吐量分析,但更关注缓存未命中的延迟。
5. TLB 延迟分析:
- 显示了 TLB 未命中的延迟。
6. CPU 循环和 L1 访问时间:
- CPU loop + L1 access: 4.39 ns = 4 cy 表示 CPU 循环加上 L1 缓存访问的时间是 4.39 纳秒,等于 4 个时钟周期。
7. Cache级别信息:
- level:缓存级别。
- size:缓存大小。
- linesize:缓存行大小。
- miss-latency:缓存未命中延迟。
- replace-time:替换时间。
例如,1 512 KB 4096 bytes 477.79 ns = 478 cy 478.30 ns = 478 cy 表示 L1 缓存大小为 512KB,行大小为 4096 字节,未命中延迟为 477.79 纳秒(478 时钟周期),替换时间为 478.30 纳秒(478 时钟周期)。
8. TLB 信息:
- level:TLB 级别。
- #entries:TLB 条目数。
- pagesize:页面大小。
- miss-latency:TLB 未命中延迟。
例如,1 80 5 KB 5.14 ns = 5 cy 表示 L1 TLB 有 80 个条目,页面大小为 5KB,未命中延迟为 5.14 纳秒(5 时钟周期)。
3.2 cache-calibrator测试结果分析
测试结束得到6个文件:file.TLB-miss-latency.data、file.cache-miss-latency.gp、file.TLB-miss-latency.gp、file.cache-replace-time.data、file.cache-miss-latency.data、 file.cache-replace-time.gp。
修改.gp文件:
- 修改set data style linespoints为set style data linespoints,然后执行gnuplot xxx.gp。
- 注释生成postscript文件的脚本,新增生成png:
set term png size 1920,1080 set output "file.TLB-miss-latency.png"
得到的图形如下。
3.2.1 cache replace time
1 坐标轴
- X轴(stride):表示内存访问的步长,即连续访问的内存地址之间的间隔。步长以字节为单位,从 16K(16384 字节)到 16M(16,777,216 字节)。
- Y轴(nanoseconds per iteration 和 cycles per iteration):表示每次迭代的纳秒数和周期数。左半部分的 Y轴 表示纳秒数,右半部分的 Y轴 表示周期数。
2 图例
- memory range [bytes]:图例中的数字表示不同的内存范围,例如 256、512、1024 等。
3 数据曲线
- 图中有多个颜色的曲线,每条曲线代表在特定步长和内存范围下的缓存替换时间。曲线的点表示在特定步长下测量的时间值。
- 曲线的陡峭程度反映了步长变化对缓存替换时间的影响。在某些步长下,时间可能会显著增加,这可能是由于缓存替换导致的。
4 参考线
- 图中有两条水平虚线,分别标记为 (3.75) 和 (481),分别为下限值和上限值。
5 测试结果分析
- 在步长较小(例如 16K 到 256K)时,cache replace time相对较低且变化不大,这表明在这些步长下,cache能够较好地处理内存访问请求,替换操作较少。
- 当步长增加到 512K 及以上时,cache replace time开始显著增加,尤其是在步长为 1M 时,时间出现了一个明显的峰值。这可能是由于缓存容量不足,导致更多的数据需要被替换出缓存。
- 在步长超过 1M 后,替换时间的增长趋势变得平缓,这可能是因为在这些步长下,缓存替换的影响已经达到了一个相对稳定的水平。
6 结论
- 该图表提供了对系统缓存性能的深入理解,特别是在不同内存访问模式下缓存替换操作的影响。
- 开发者可以利用这些信息来优化程序的内存访问模式,减少缓存替换,从而提高程序的性能。
3.2.2 cache miss latency
1 坐标轴
- X轴(stride):表示内存访问的步长,即连续访问的内存地址之间的间隔。步长以字节为单位,从 16K(16384 字节)到 16M(16,777,216 字节)。
- Y轴(nanoseconds per iteration 和 cycles per iteration):表示每次迭代的纳秒数和周期数。左半部分的 Y轴 表示纳秒数,右半部分的 Y轴 表示周期数。
2 图例
- memory range [bytes]:图例中的数字表示不同的内存范围,例如 256、512、1024 等。
3 数据曲线
- 图中有多个颜色的曲线,每条曲线代表在特定步长和内存范围下的缓存未命中延迟。曲线的点表示在特定步长下测量的延迟值。
- 曲线的陡峭程度反映了步长变化对缓存未命中延迟的影响。在某些步长下,延迟可能会显著增加,这可能是由于缓存未命中导致的。
4 参考线
- 图中有两条水平虚线,分别标记为 (3.75) 和 (484),分别为下限值和上限值。
5 测试结果分析
- 在步长较小(例如 16K 到 256K)时,缓存未命中延迟相对较低且变化不大,这表明在这些步长下,缓存能够较好地处理内存访问请求。
- 当步长增加到 512K 及以上时,缓存未命中延迟开始显著增加,尤其是在步长为 1M 时,延迟出现了一个明显的峰值。这可能是由于缓存容量不足,导致更多的数据需要从主内存中加载。
- 在步长超过 4M 后,延迟的增长趋势变得平缓,这可能是因为在这些步长下,缓存未命中的影响已经达到了一个相对稳定的水平。
6 结论
- 该图表提供了对系统缓存性能的深入理解,特别是在不同内存访问模式下的表现。
- 开发者可以利用这些信息来优化程序的内存访问模式,减少缓存未命中,从而提高程序的性能。
3.2.3 TLB miss latency
1 坐标轴
- X轴(stride):表示内存访问的步长,即连续访问的内存地址之间的间隔。步长越大,表示访问的内存地址之间的间隔越大。
- Y轴(nanoseconds per iteration 和 cycles per iteration):表示每次迭代的纳秒数和周期数。左半部分的 Y轴 表示纳秒数,右半部分的 Y轴 表示周期数。
2 图例
- spots accessed:表示在测试中访问的不同内存位置的数量。
3 数据曲线
- 图中有两条曲线(不同spots accessed),分别表示在不同步长下,TLB 未命中的延迟。曲线的点表示在特定步长下测量的延迟值。
- 曲线的陡峭程度反映了步长变化对 TLB 未命中延迟的影响。在某些步长下,延迟可能会显著增加,这可能是由于 TLB 未命中导致的。
4 参考线
- 图中有两条水平虚线,分别标记为 (5) 和 (13.8),这可能表示在特定步长下的理论或预期的延迟值。
5 测试结果分析
- 在步长较小(例如 4 到 64)时,TLB 未命中延迟相对较低且变化不大,这表明在这些步长下,TLB 能够较好地处理内存访问请求。
- 当步长增加到 128 及以上时,TLB 未命中延迟开始显著增加,尤其是在步长为 256 时,延迟出现了一个明显的峰值。这可能是由于 TLB 条目不足,导致更多的地址映射需要从页面表中查找。
- 在步长超过 512 后,延迟的增长趋势变得平缓,这可能是因为在这些步长下,TLB 未命中的影响已经达到了一个相对稳定的水平。
6 结论
- 该图表提供了对系统 TLB 性能的深入理解,特别是在不同内存访问模式下的表现。
- 开发者可以利用这些信息来优化程序的内存访问模式,减少 TLB 未命中,从而提高程序的性能。
4 coremark
CoreMark 是一个用于评估处理器性能的基准测试程序,它通过模拟一个小型嵌入式程序的工作负载来提供标准化的性能度量。
2K performance run parameters for coremark. CoreMark Size : 666--表示 CoreMark 测试中使用的矩阵大小,它影响测试的复杂度和执行时间。 Total ticks : 14294 Total time (secs): 14.294000 Iterations/Sec : 4197.565412 Iterations : 60000 Compiler version : GCC13.3.0 Compiler flags : -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -lrt Memory location : Please put data memory location here (e.g. code in flash, data on heap etc) seedcrc : 0xe9f5 [0]crclist : 0xe714 [0]crcmatrix : 0x1fd7 [0]crcstate : 0x8e3a [0]crcfinal : 0xbd59 Correct operation validated. See readme.txt for run and reporting rules. CoreMark 1.0 : 4197.565412 / GCC13.3.0 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -lrt / Heap
5 coremark-pro
coremark-pro基准测试包括9个负载,分别是:
-
cjpeg-rose7-preset:这个工作负载模拟JPEG图像压缩过程,主要涉及整数计算,尤其是对于颜色转换和DCT(离散余弦变换)。
-
loops-all-mid-10k-sp:基于Livermore Loops基准测试,这个工作负载主要涉及整数循环和数组操作。
-
parser-125k:模拟XML文档的解析过程,主要涉及整数计算,用于处理标记和属性。
-
sha-test:模拟SHA-256哈希算法,主要涉及整数计算,用于位操作和逻辑运算。
-
zip-test:模拟ZIP文件压缩过程,主要涉及整数计算,用于处理数据压缩算法。
-
core:CoreMark的基本测试,包含一些浮点计算,尤其是在数学函数和矩阵操作中。
-
linear_alg-mid-100x100-sp:执行基于LINPACK的高斯消元法,主要涉及浮点计算,用于线性代数运算。
-
nnet_test:模拟神经网络算法,主要涉及浮点计算,用于处理权重和激活函数。
-
radix2-big-64k:执行基于FFT(快速傅立叶变换)的算法,主要涉及浮点计算,用于信号处理和科学计算。
WORKLOAD RESULTS TABLE MultiCore SingleCore Workload Name (iter/s) (iter/s) Scaling ----------------------------------------------- ---------- ---------- ---------- cjpeg-rose7-preset 33.00 26.81 1.23 core 0.22 0.21 1.05 linear_alg-mid-100x100-sp 8.94 6.97 1.28 loops-all-mid-10k-sp 0.49 0.49 1.00 nnet_test 0.35 0.37 0.95 parser-125k 5.85 5.88 0.99 radix2-big-64k 59.98 62.34 0.96 sha-test 37.88 38.46 0.98 zip-test 12.35 13.33 0.93 MARK RESULTS TABLE Mark Name MultiCore SingleCore Scaling ----------------------------------------------- ---------- ---------- ---------- CoreMark-PRO 571.00 551.52 1.04