On Fri, Jul 17, 2020 at 11:46:37AM +0100, Lorenz Bauer wrote: > Hi list, > > I'm not sure whether this is a bug report or just the way of life. > The problem: we have a couple of machines that run KASAN > kernels to weed out bugs. On those machines, loading our > cls-redirect TC classifier takes so long that our user space > program aborts. > > I've reproduced this in a VM: loading cls-redirect on a VM > with a 5.4 kernel without KASAN takes around 4 seconds. > Doing the same on recent bpf-next with KASAN and other > shenanigans enabled it takes more like a minute. a minute to load single program? that sounds high. While processing patches I build the kernel with kasan and lockdep. None of test_progs and test_verifier programs have such drastic slowdowns. I'm not sure what is the reason. do you use kasan inline or outline ? > Is it expected that the overhead of KASAN is this large? sounds like 20x overhead ? I think 10x is normal. > I went and collected a perf profile of loading the program > in the VM: > > - 96.31% 1.00% redirect.test [kernel.kallsyms] [k] do_check_common > - 95.32% do_check_common > - 69.24% states_equal.isra.0 > + 49.81% kmem_cache_alloc_trace > + 16.77% kfree > + 1.22% regsafe.part.0 > - 12.75% push_stack > - 10.65% copy_verifier_state > - 4.50% realloc_stack_state > + 4.48% __kmalloc > + 4.16% kmem_cache_alloc_trace > + 1.82% __kmalloc > + 2.07% kmem_cache_alloc_trace > + 5.25% pop_stack > + 2.84% push_jmp_history.isra.0 > + 2.46% copy_verifier_state > + 1.00% free_verifier_state > 0.53% kmem_cache_alloc_trace > + 1.00% runtime.goexit the perf profile makes sense. how many insn it processed? what are test_progs -s stats ?
