我有一个python程序，它使用许多进程在指定的时间内运行附加卡。我基于一个旧的perl程序。
该计划并没有尽可能多地强调附加卡。它导致性能大约是旧perl程序的60％，并且它应该至少是旧perl程序性能的2倍，因为我通过内存而不是磁盘驱动器发送数据。
我注意到来自iostat -c -d -x -t -m /dev/md127 2的％系统在新的python程序上大约是20-25％，在旧的perl程序中是5-10％，所以我根据这个问题运行了perf：{{3 }}
这些是来自perf record -a -g python ...和perf report -g graph的新python程序的结果。我在两个不同的系统上尝试了这个，并且都显示了一个很高的＆＃34; ktime_get＆＃34;和＆＃34; read_hpet＆＃34;。
我的程序使用multiprocessing.pool来运行while time.time() < numberOfMinutes:，但下面的perf结果来自我将池大小设置为1的运行。
在这些系统上我对高精度定时器的竞争很激烈吗？
Samples: 388K of event 'cycles', Event count (approx.): 1345230671182
Children Self Command Shared Object Symbol ◆
+ 35.81% 0.24% swapper [kernel.kallsyms] [k] cpu_startup_entry ¦
+ 29.27% 0.00% swapper [kernel.kallsyms] [k] start_secondary ¦
- 27.64% 0.15% swapper [kernel.kallsyms] [k] ktime_get ¦
- ktime_get ¦
+ 10.93% clockevents_program_event ¦
+ 5.23% cpuidle_enter_state ¦
+ 4.02% sched_clock_tick ¦
+ 3.55% tick_nohz_idle_exit ¦
+ 3.35% __tick_nohz_idle_enter ¦
+ 0.43% tick_check_idle ¦
+ 0.05% tick_sched_timer ¦
+ 0.04% clockevents_program_min_delta ¦
+ 0.01% cpuidle_idle_call ¦
+ 0.01% tick_program_event ¦
+ 0.00% intel_pstate_timer_func ¦
+ 0.00% tick_nohz_idle_enter ¦
+ 0.00% cpu_startup_entry ¦
+ 0.00% sched_clock_idle_wakeup_event ¦
+ 0.00% poll_idle ¦
+ 0.00% irq_enter ¦
- 27.60% 27.60% swapper [kernel.kallsyms] [k] read_hpet ¦
- 27.60% 27.60% swapper [kernel.kallsyms] [k] read_hpet ¦
- read_hpet ¦
+ 27.49% ktime_get ¦
+ 0.07% ktime_get_update_offsets_now ¦
+ 0.01% update_wall_time ¦
+ 0.01% __tick_nohz_idle_enter ¦
+ 0.01% clockevents_program_event ¦
+ 0.01% cpuidle_enter_state ¦
+ 0.00% tick_nohz_idle_exit ¦
+ 0.00% sched_clock_tick ¦
+ 0.00% hrtimer_interrupt ¦
+ 13.79% 0.03% swapper [kernel.kallsyms] [k] tick_nohz_idle_exit ¦
+ 11.58% 0.03% swapper [kernel.kallsyms] [k] tick_program_event ¦
+ 11.57% 0.10% swapper [kernel.kallsyms] [k] clockevents_program_event ¦
+ 9.93% 0.01% swapper [kernel.kallsyms] [k] arch_cpu_idle ¦
+ 9.90% 0.08% swapper [kernel.kallsyms] [k] cpuidle_idle_call ¦
+ 9.81% 0.16% swapper [kernel.kallsyms] [k] hrtimer_start_range_ns ¦
+ 9.79% 0.03% swapper [kernel.kallsyms] [k] __tick_nohz_idle_enter ¦
▒
更新 发现高＆＃34; read_hpet＆＃34;来自multiprocessing.manager列表。我有一个函数，它生成一个进程并遍历一个目录，将每个文件添加到manager.list（）。没有这个，`perf record -a -g python ......＆＃39;给我看下面的报告。现在我正在运行一些实验，看看我是否仍然在不使用manager.list（）的情况下获得缓慢的性能。为什么从os.walk（）构建manager.list（）会如此多地使用高精度计时器？
Samples: 118K of event 'cycles', Event count (approx.): 344546484735
Children Self Command Shared Object Symbol
+ 12.80% 0.01% python [kernel.kallsyms] [k] system_call_fastpath
+ 9.45% 0.00% python libpython2.7.so.1.0 [.] 0xffff80585ab02ae0
+ 8.88% 0.06% python libc-2.17.so [.] __xstat64
+ 8.81% 0.03% python [kernel.kallsyms] [k] vfs_fstatat
+ 8.43% 0.01% python [kernel.kallsyms] [k] sys_newstat
+ 8.41% 0.02% python [kernel.kallsyms] [k] SYSC_newstat
+ 8.27% 0.01% python [kernel.kallsyms] [k] user_path_at
+ 8.25% 0.03% python [kernel.kallsyms] [k] user_path_at_empty
+ 8.08% 8.05% python libpython2.7.so.1.0 [.] PyEval_EvalFrameEx
+ 8.03% 0.00% python multiarray.so [.] 0xffff8058641f12c0
+ 7.89% 0.02% python [kernel.kallsyms] [k] filename_lookup
+ 7.83% 0.10% python [kernel.kallsyms] [k] path_lookupat
+ 6.37% 0.00% python libpython2.7.so.1.0 [.] 0xffff80585ab03940
+ 4.36% 0.00% python [unknown] [.] 0000000000000000
+ 3.94% 0.00% python multiarray.so [.] 0xffff8058641f1120
+ 3.56% 0.03% swapper [kernel.kallsyms] [k] cpu_startup_entry
+ 3.56% 0.90% python [kernel.kallsyms] [k] link_path_walk
+ 3.39% 0.00% python [unknown] [.] 0x6c2f746573617461
+ 3.10% 0.04% python libc-2.17.so [.] __getdents64
+ 3.08% 0.00% python [unknown] [.] 0x6d2f746573617461
+ 2.98% 0.02% python [kernel.kallsyms] [k] lookup_slow