Message ID | 20230127130541.1250865-1-chenguokai17@mails.ucas.ac.cn (mailing list archive) |
---|---|
Headers | show |
Series | Add OPTPROBES feature on RISCV | expand |
Chen Guokai <chenguokai17@mails.ucas.ac.cn> writes:
> Add jump optimization support for RISC-V.
I'd like to take the series for a spin, but I'm having trouble applying
the the patches; What base commit did you use? Or point me to a git
repo.
(It's nice to use "--base" to git-format-patch.)
Thanks!
Björn
Hi Björn, > 2023年1月30日 20:31,Björn Töpel <bjorn@kernel.org> 写道: > > Chen Guokai <chenguokai17@mails.ucas.ac.cn> writes: > >> Add jump optimization support for RISC-V. > > I'd like to take the series for a spin, but I'm having trouble applying > the the patches; What base commit did you use? Or point me to a git > repo. I generated this patch series based on next-20230127 tag > > (It's nice to use "--base" to git-format-patch.) I will take this parameter in any following revisions, thanks! > > > Thanks! > Björn
Chen Guokai <chenguokai17@mails.ucas.ac.cn> writes: > Add jump optimization support for RISC-V. > > Replaces ebreak instructions used by normal kprobes with an AUIPC/JALR > instruction pair with the aim of suppressing the probe-hit overhead. > > All known optprobe-capable RISC architectures have been using a single > jump or branch instructions while this patch chooses not. RISC-V has a > quite limited jump range (4KB or 2MB) for both its branch and jump > instructions, which prevent optimizations from supporting probes that > spread all over the kernel. > > AUIPC/JALR instruction pair is introduced with a much wider jump range > (4GB), where AUIPC loads the upper 12 bits to a free register and JALR > Deaconappends the lower 20 bits to form a 32 bits immediate. Note that > returns from probe handler require another free register. As kprobes > can appear almost anywhere inside the kernel, the free register should > be found generically, not depending on calling convention or any other > regulations. > > The algorithm for finding the free register is inspired by the register > renaming in modern processors. From the perspective of register > renaming, a register could be represented as two different registers if > two neighbor instructions both write to it but no one ever reads it. > Extending this fact, a register is considered to be free if there is no > read before its next write in the execution flow. We are free to change > its value without interfering normal execution. > > Static analysis shows that 51% of instructions of the kernel (default > config) is capable of being replaced i.e. one free register can be found > at both the start and end of replaced instruction pairs while the > replaced instructions can be directly executed. We also made an > efficiency test on Gem 5 RISCV which shows a more than 5x speedup on > breakpoint-based implementation. > > Contribution: > Chen Guokai invents the algorithm for searching free register, evaluate > the ratio of optimization, the basic function support RVI kernel binary. > Liao Chang adds the support for hybrid RVI and RVC kernel binary, fix > some bugs with different kernel configure, refactor out the entire > feature into some individual patches. Thank you for continuing to work on this series! I took it for a spin, and it worked nicely on my QEMU setup. It would be nice to have it run on some *actual* hardware as well. :-) I have some additional comments on the series, but I'll add those to the relevant patch. It's mostly minor things! Björn
On Mon, 30 Jan 2023 06:38:42 PST (-0800), chenguokai17@mails.ucas.ac.cn wrote: > Hi Björn, > > > >> 2023年1月30日 20:31,Björn Töpel <bjorn@kernel.org> 写道: >> >> Chen Guokai <chenguokai17@mails.ucas.ac.cn> writes: >> >>> Add jump optimization support for RISC-V. >> >> I'd like to take the series for a spin, but I'm having trouble applying >> the the patches; What base commit did you use? Or point me to a git >> repo. > > I generated this patch series based on next-20230127 tag > >> >> (It's nice to use "--base" to git-format-patch.) > > I will take this parameter in any following revisions, thanks! Just checking up on this one, it's got some feedback that seems reasonable. Sorry if I missed the v7, but I'm dropping the v6 from patchwork. If there's no v7 on the lists it's probably too late for 6.4, so no rush on my end. Thanks! > >> >> >> Thanks! >> Björn