On Wed, Nov 16, 2022 at 02:33:37PM -0800, Luis Chamberlain wrote: > On Tue, Nov 15, 2022 at 02:48:05PM -0800, Song Liu wrote: > > On Tue, Nov 15, 2022 at 1:09 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > > > > > On Mon, Nov 14, 2022 at 05:30:39PM -0800, Song Liu wrote: > > > > On Mon, Nov 7, 2022 at 2:41 PM Song Liu <song@xxxxxxxxxx> wrote: > > > > > > > Currently, I have got the following action items for v3: > > > > 1. Add unify API to allocate text memory to motivation; > > > > 2. Update Documentation/x86/x86_64/mm.rst; > > > > 3. Allow none PMD_SIZE allocation for powerpc. > > > > > > - I am really exausted of asking again for real performance tests, > > > you keep saying you can't and I keep saying you can, you are not > > > trying hard enough. Stop thinking about your internal benchmark which > > > you cannot publish. There should be enough crap out which you can use. > > > > > > - A new selftest or set of selftests which demonstrates gain in > > > performance > > > > I didn't mean to not show the result with publically available. I just > > thought the actual benchmark was better (and we do use that to > > demonstrate the benefit of a lot of kernel improvement). > > > > For something publically available, how about the following: > > > > Run 100 instances of the following benchmark from bpf selftests: > > tools/testing/selftests/bpf/bench -w2 -d100 -a trig-kprobe > > which loads 7 BPF programs, and triggers one of them. > > > > Then use perf to monitor TLB related counters: > > perf stat -e iTLB-load-misses,itlb_misses.walk_completed_4k, \ > > itlb_misses.walk_completed_2m_4m -a > > > > The following results are from a qemu VM with 32 cores. > > > > Before bpf_prog_pack: > > iTLB-load-misses: 350k/s > > itlb_misses.walk_completed_4k: 90k/s > > itlb_misses.walk_completed_2m_4m: 0.1/s > > > > With bpf_prog_pack (current upstream): > > iTLB-load-misses: 220k/s > > itlb_misses.walk_completed_4k: 68k/s > > itlb_misses.walk_completed_2m_4m: 0.2/s > > > > With execmem_alloc (with this set): > > iTLB-load-misses: 185k/s > > itlb_misses.walk_completed_4k: 58k/s > > itlb_misses.walk_completed_2m_4m: 1/s > > > > Do these address your questions with this? > > More in lines with what I was hoping for. Can something just do > the parallelization for you in one shot? Can bench alone do it for you? > Is there no interest to have soemthing which generically showcases > multithreading / hammering a system with tons of eBPF JITs? It may > prove useful. > > And also, it begs the question, what if you had another iTLB generic > benchmark or genearl memory pressure workload running *as* you run the > above? I as, as it was my understanding that one of the issues was the > long term slowdown caused by the directmap fragmentation without > bpf_prog_pack, and so such an application should crawl to its knees > over time, and there should be numbers you could show to prove that > too, before and after. I'd add to that that benchmarking iTLB performance on an idle system is not very representative. TLB is a scarce resource, so it'd be interesting to see this benchmark on a loaded system. > Luis -- Sincerely yours, Mike.
