Vasilev Oleg <vasilev.o...@huawei.com> writes:
> On 12/3/2021 8:32 PM, Alex Bennée wrote: >> Vasilev Oleg <vasilev.o...@huawei.com> writes: >> >>> On 12/2/2021 7:02 PM, Alex Bennée wrote: >>> >>>> Vasilev Oleg <vasilev.o...@huawei.com> writes: > ...skipped... >>>> I did ponder a debug mode which would keep the last N tables dropped by >>>> tlb_mmu_resize_locked and then measure the differences in the entries >>>> before submitting the free to an rcu tasks. >>>>> The mentioned paper[4] also describes other possible improvements. >>>>> Some of those are already implemented (such as victim TLB and dynamic >>>>> size for TLB), but others are not (e.g. TLB lookup uninlining and >>>>> set-associative TLB layer). Do you think those improvements >>>>> worth trying? >>>> Anything is worth trying but you would need hard numbers. Also its all >>>> too easy to target micro benchmarks which might not show much difference >>>> in real world use. >>> The mentioned paper presents some benchmarking, e. g. linux kernel >>> compilation and some other stuff. Do you think those shouldn't be >>> trusted? >> No they are good. To be honest it's the context switches that get you. >> Look at "info jit" between a normal distro and a initramfs shell. Places >> where the kernel is switching between multiple maps means a churn of TLB >> data. >> >> See my other post with a match of "msr ttrb" > Sorry, couldn't find what you are referring to. Could you, please, share > a link? It was an enhancement to the libinsns.so plugin to gauge how often certain instructions are run: Subject: [RFC PATCH 0/2] insn plugin tweaks for measuring frequency Date: Fri, 3 Dec 2021 14:44:19 +0000 Message-Id: <20211203144421.1445232-1-alex.ben...@linaro.org> I think the msr ttrb[10]_el1 is a key instruction because that triggers a flush if the ASID changes. On my initramfs setup with a simple login shell that doesn't happen, on a full distro there is context switching all the time which causes extra flushes. -- Alex Bennée
