Messages in this thread | | | Date | Mon, 9 May 2022 22:26:20 +0800 | From | Jisheng Zhang <> | Subject | Re: [PATCH v2 0/4] unified way to use static key and optimize pgtable_l4_enabled |
| |
On Mon, May 09, 2022 at 10:07:16AM +0530, Anup Patel wrote: > On Sun, May 8, 2022 at 9:46 PM Jisheng Zhang <jszhang@kernel.org> wrote: > > > > Currently, riscv has several features which may not be supported on all > > riscv platforms, for example, FPU, SV48, SV57 and so on. To support > > unified kernel Image style, we need to check whether the feature is > > suportted or not. If the check sits at hot code path, then performance > > will be impacted a lot. static key can be used to solve the issue. In > > the past, FPU support has been converted to use static key mechanism. > > I believe we will have similar cases in the future. For example, the > > SV48 support can take advantage of static key[1]. > > > > patch1 is a simple W=1 warning fix. > > patch2 introduces an unified mechanism to use static key for riscv cpu > > features. > > patch3 converts has_cpu() to use the mechanism. > > patch4 uses the mechanism to optimize pgtable_l4|[l5]_enabled. > > > > [1] http://lists.infradead.org/pipermail/linux-riscv/2021-December/011164.html > > Overall, using a script to generate CPU capabilities seems a bit > over-engineered to me. We already have RISC-V ISA extension
Not all riscv features are *ISA* extensions. For example, SV48 and SV57 are not ISA extensions. IIRC, I asked this question before, here are Atish's comments:
https://lore.kernel.org/linux-riscv/CAHBxVyF65jC_wvxcD6bueqpCY8-Kbahu1yxsSoBmO1s15dGkSQ@mail.gmail.com/
> parsing infrastructure which can be easily extended to support > static key arrays. >
| |