$cat /sys/devices/system/cpu/cpu0/cache/index*/number_of_sets
64:指令缓存行
64:L1D数据缓存行
512:L2数据缓存行
12288:L3数据缓存行
# 设置捕捉L2缓存IN事件
$ sudo opcontrol --setup --event=l2_lines_in:100000
# 清空工作区
$ sudo opcontrol --reset
# 开始捕捉
$ sudo opcontrol --start
# 运行程序
$ java FalseSharing
# 程序跑完后, dump捕捉到的数据
$ sudo opcontrol --dump
# 停止捕捉
$ sudo opcontrol -h
# 报告结果
$ opreport -l `which java`
结果示例如下:
CPU: Intel Sandy Bridge microarchitecture, speed 2300.24 MHz (estimated)
Counted l2_lines_in events (L2 cache lines in) with a unit mask of 0x07 (all L2 cache lines filling L2) count 100000
samples % image name symbol name
14914 100.000 anon (tgid:9752 range:0x7fddb8424000-0x7fddb8694000) anon (tgid:9752 range:0x7fddb8424000-0x7fddb8694000)
结果中,samples的数值越高,说明l2_lines_in触发的次数越多。
本地的结果如下:
CPU: Intel Sandy Bridge microarchitecture, speed 2300.24 MHz (estimated)
均运行在4个cpu逻辑核心上。
名称 |
备注 |
时间(秒) |
l1d次数 |
l2_lines_in次数 |
l2_trans次数 |
FlaseSharing |
有L1D竞争 |
259 |
1473 |
37439 |
156777 |
FalseSharing2 |
没有L1D竞争 |
40 |
501 |
31778 |
41114 |
AffinityFalseSharingDifferentSocket |
有L1D竞争,每个socket上有两个逻辑核心 |
217 |
1527 |
43370 |
101298 |
AffinityFalseSharingSameCore |
有L1D竞争,同一个socket上的2个core上4个逻辑核心 |
26 |
400 |
13673 |
22382 |
AffinityFalseSharingSameSocket |
有L1D竞争,同一个socket上的4个core上4个逻辑核心 |
44 |
912 |
35217 |
42213 |
第二组测试,限定使用2个逻辑核心
名称 |
备注 |
时间(秒) |
l1d次数 |
l2_lines_in次数 |
l2_trans次数 |
预期结果 |
FlaseSharing |
有L1D竞争 |
77 |
472 |
18941 |
25000 |
近似 |
FalseSharing2 |
没有L1D竞争 |
51 |
271 |
6316 |
14925 |
近似 |
AffinityFalseSharingDifferentSocket |
有L1D竞争,2个socket上的2个逻辑核心 |
54 |
429 |
16803 |
28851 |
|
AffinityFalseSharing2DifferentSocket |
没有L1D竞争,2个socket上的2个逻辑核心 |
30 |
— |
— |
— |
|
AffinityFalseSharingSameCore |
有L1D竞争,1个socket上的2个core上2个逻辑核心 |
21 |
284 |
10528 |
14900 |
待确认 |
AffinityFalseSharing2SameCore |
没有L1D竞争,1个socket上的2个core上2个逻辑核心 |
31 |
725 |
15930 |
30264 |
待确认 |
AffinityFalseSharingSameSocket |
有L1D竞争,1个socket上的2个core上2个逻辑核心 |
35 |
661 |
16019 |
27445 |
|
AffinityFalseSharing2SameSocket |
没有L1D竞争,1个socket上的2个core上2个逻辑核心 |
20 |
322 |
11877 |
16513 |
|
l1d: (counter: all)
L1D cache events (min count: 2000000)
Unit masks (default 0x1)
----------
0x01: replacement L1D Data line replacements.
0x02: allocated_in_m L1D M-state Data Cache Lines Allocated
0x04: eviction L1D M-state Data Cache Lines Evicted due to replacement (only)
0x08: all_m_replacement All Modified lines evicted out of L1D
l2_l1d_wb_rqsts: (counter: all)
writebacks from L1D to the L2 cache (min count: 200000)
Unit masks (default 0x4)
----------
0x04: hit_e writebacks from L1D to L2 cache lines in E state
0x08: hit_m writebacks from L1D to L2 cache lines in M state
l1d_pend_miss: (counter: 2)
Cycles with L1D load Misses outstanding. (min count: 2000000)
Unit masks (default 0x1)
----------
0x01: pending Cycles with L1D load Misses outstanding.
0x01: occurences This event counts the number of L1D misses outstanding occurences.
(extra: edge cmask=1)
l1d_blocks: (counter: all)
L1D cache blocking events (min count: 100000)
Unit masks (default 0x1)
----------
0x01: ld_bank_conflict Any dispatched loads cancelled due to DCU bank conflict
0x05: bank_conflict_cycles Cycles with l1d blocks due to bank conflicts (extra: cmask=1)
l2_trans: (counter: all)
L2 cache accesses (min count: 200000)
Unit masks (default 0x80)
----------
0x80: all_requests Transactions accessing L2 pipe
0x01: demand_data_rd Demand Data Read requests that access L2 cache, includes L1D
prefetches.
0x02: rfo RFO requests that access L2 cache
0x04: code_rd L2 cache accesses when fetching instructions including L1D code prefetches
0x08: all_pf L2 or LLC HW prefetches that access L2 cache
0x10: l1d_wb L1D writebacks that access L2 cache
0x20: l2_fill L2 fill requests that access L2 cache
0x40: l2_wb L2 writebacks that access L2 cache
l2_lines_in: (counter: all)
L2 cache lines in (min count: 100000)
Unit masks (default 0x7)
----------
0x07: all L2 cache lines filling L2
0x01: i L2 cache lines in I state filling L2
0x02: s L2 cache lines in S state filling L2
0x04: e L2 cache lines in E state filling L2
l2_lines_out: (counter: all)
L2 cache lines out (min count: 100000)
Unit masks (default 0x1)
----------
0x01: demand_clean Clean line evicted by a demand
0x02: demand_dirty Dirty line evicted by a demand
0x04: pf_clean Clean line evicted by an L2 Prefetch
0x08: pf_dirty Dirty line evicted by an L2 Prefetch
0x0a: dirty_all Any Dirty line evicted
附二:
# 查看缓存大小
$ls /sys/devices/system/cpu/cpu0/cache/
index0 index1 index2 index3
4个目录
index0:1级数据cache
index1:1级指令cache
index2:2级cache
index3:3级cache ,对应cpuinfo里的cache
目录里的文件是cache信息描述,以本机的cpu0/index0为例简单解释一下:
文件 |
内容 |
说明 |
type |
Data |
数据cache,如果查看index1就是Instruction |
Level |
1 |
L1 |
Size |
32K |
大小为32K |
coherency_line_size |
64 |
64*4*128=32K
physical_line_partition |
1 |
ways_of_associativity |
4 |
number_of_sets |
128 |
shared_cpu_map |
00000101 |
表示这个cache被CPU0和CPU8 share |
解释一下shared_cpu_map内容的格式:
表面上看是2进制,其实是16进制表示,每个bit表示一个cpu,1个数字可以表示4个cpu
截取00000101的后4位,转换为2进制表示
CPU id |
15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
0×0101的2进制表示 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0101表示cpu8和cpu0,即cpu0的L1 data cache是和cpu8共享的。
验证一下?
cat /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_map
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000101
再看一下index3 shared_cpu_map的例子
cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_map
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000f0f
CPU id |
15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
0x0f0f的2进制表示 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
cpu0,1,2,3和cpu8,9,10,11共享L3 cache
参考:
1. http://itindex.net/detail/37419-java-视角-理解
2. http://www.searchtb.com/2012/12/玩转cpu-topology.html
相关推荐
使用 OProfile 可以收集有关处理器事件的信息,包括 TLB 的故障、停机、存储器访问、位于 DCU(数据高速缓存单元)中的总线路数、一个 DCU 故障的周期数,以及不可高速缓存的和可高速缓存的指令的获取数量。...
硬件计数器可以记录特定事件的发生次数,如CPU周期、缓存未命中的次数等。当计数器达到预设阈值时,会触发中断,内核捕获这些事件并记录相关信息。然后,Oprofile的用户空间组件将这些数据收集、整理,最终生成可读...
Oprofile是一款强大的Linux性能分析工具,它可以在系统级别对各种硬件事件进行采样,如CPU周期、缓存命中、指令执行等,从而帮助开发者和系统管理员深入理解系统运行时的行为,找出性能瓶颈。在"oprofile-0.9.5.tar....
Oprofile是Linux内核级别的性能分析器,通过在内核级别收集硬件事件(如CPU周期、缓存命中、分支指令等)来提供系统级的性能数据。它支持多种处理器架构,包括x86, x86_64, PowerPC, IA64等,能够对用户空间程序、...
1. **CPU事件采样**:Oprofile能够监控CPU的各种活动,如指令执行、缓存引用、分支预测等,通过采样这些事件,可以了解程序运行时的热点区域。 2. **内核模块分析**:Oprofile不仅限于用户空间的应用程序,它还能...
- Oprofile是一个开源的、对系统性能影响较小的工具,它利用CPU的硬件性能监控单元来收集系统内核和可执行文件的运行信息,包括内存交互、二级缓存未命中次数和中断处理等。 - 工作原理分为两类:基于事件的采样和...
通过对处理器事件的跟踪,如TLB故障、停顿时间、内存访问频率、DCU中的总线活动情况、DCU故障周期、非缓存和缓存指令的获取次数等,Oprofile能够提供详尽的数据支持,辅助开发者定位性能瓶颈所在。 #### 二、...
3. **配置**:根据需要,可以使用`opcontrol --help`查看配置选项,例如设置采样频率、选择要监控的事件等。 4. **启动**:使用`sudo opcontrol --start`命令启动Oprofile服务。 5. **监控**:在Oprofile运行期间...
- 不同的硬件支持不同的性能计数器事件,通过`opcontrol --show-events`命令可以查看当前系统支持的事件。 3. **设置JIT(即时编译)功能**: - 对于运行时动态编译的代码(如JIT编译的Java代码),需要启用特定的...
硬件性能计数器是现代处理器中内置的一种机制,它们可以监控特定的事件,如CPU周期、缓存未命中的次数、分支预测失败等。OProfile能够灵活地配置这些计数器,针对不同的分析需求选择关注的指标。通过对这些事件的...
它的主要作用是收集系统级的性能数据,包括CPU周期、缓存命中率、指令执行情况等,用于定位程序的性能瓶颈。OProfile 0.9.99是该工具的一个版本,它可能包含了一些新的特性或改进,以适应不断发展的硬件和软件需求。...
使用`opcontrol --reset`和`opcontrol --v`来检查和初始化oprofile。 在实际使用中,这些工具可以帮助管理员深入了解系统运行状态,及时发现潜在问题,并进行相应的优化调整。务必熟悉每个工具的特性和用法,以充分...
- **Systrace**:用于分析系统层面的执行流程,包括CPU、GPU、输入事件等,通过时间线视图直观展示各组件的执行情况。 - **Traceview**:针对Java层的性能分析工具,可以追踪单个方法的执行时间,帮助找出耗时操作...