Menu
▾
▴
samples lost due to no permanent mapping and no file mapping
|
From: J L. <joh...@ho...> - 2020-07-21 01:03:01
|
Oprofiling an intensive postgresql workload running on a Lenovo P52 and lniux kernel 5.7.4, I see very high numbers of both of these : approximately two-thirds of all user-space samples are being lost. see operf.log below The operf command I've used is operf --vmlinux /mnt/bullbild/linux-5.7.4-bullarch/vmlinux --session-dir /tmp/oprof_session.200720-195024 --events cpu_clk_unhalted:30000045:thread:1:1 --callgraph --separate-cpu --system-wide and it works but tells me WARNING: Lost samples detected! See /tmp/oprof_session.200720-195024/samples/operf.log for details. Lowering the sampling rate as suggested does not help : I tried with a count of 99999999 and same high lost samples. I assume oprofile somehow is unable to map the instruction pointer of the event to any process? How does it do this? Is there any setting or control or hint that I can set to help it? or , failing that, is there any way I can ask opreport to give me the results as raw instruction addresses? Help! Cheers, John Lumby ___________________________________________________________ Profiling started at Mon Jul 20 19:50:24 2020 Profiling stopped at Mon Jul 20 19:51:25 2020 -- OProfile/operf Statistics -- Nr. non-backtrace samples: 9435 Nr. kernel samples: 1924 Nr. user space samples: 7511 Nr. samples lost due to sample address not in expected range for domain: 0 Nr. lost kernel samples: 0 Nr. samples lost due to sample file open failure: 0 Nr. samples lost due to no permanent mapping: 4967 Nr. user context kernel samples lost due to no app info available: 0 Nr. user samples lost due to no app info available: 0 Nr. backtraces skipped due to no file mapping: 4967 Nr. hypervisor samples dropped due to address out-of-range: 0 Nr. samples lost reported by perf_events kernel: 0 |