On Mon, Mar 25, 2019 at 9:46 AM Stanislav Fomichev <s...@fomichev.me> wrote: > > On 03/25, Daniel Borkmann wrote: > > On 03/19/2019 10:53 PM, Stanislav Fomichev wrote: > > > When running stacktrace_build_id_nmi, try to query > > > kernel.perf_event_max_sample_rate sysctl and use it as a sample_freq. > > > If there was an error reading sysctl, fallback to 5000. > > > > > > kernel.perf_event_max_sample_rate sysctl can drift and/or can be > > > adjusted by the perf tool, so assuming a fixed number might be > > > problematic on a long running machine. > > > > > > Signed-off-by: Stanislav Fomichev <s...@google.com> > > > > Mostly trying to understand rationale a bit better in context of > > selftests; perf_event_max_sample_rate could drift also after this > > patch here, but I presume you are saying that the frequency we > > request below would interfere too much with perf tool adjusted > > one and thus affect whole rest of kernel also after selftests > > finished running, so below would handle it more gracefully, right? > Not really, the kernel would straight out reject out attempt > to syscall(perf_event_open) when sample_freq >= > kernel.perf_event_max_sample_rate sysctl: > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/kernel/events/core.c#n10724 > > For this test, we don't really care about specific sample_freq, we just > want our bpf prog to trigger at least once, so we can check the > build-id. > > Maybe another way to fix it would be to convert to sample_period. > Song, any specific reason you went with sample_freq and not > sample_period in your original proposal?
I guess it's fine as-is. Applied to bpf-next. Thanks
