On Tue, Apr 04, 2023 at 08:50:16AM +0200, Arnd Bergmann wrote: > On Tue, Apr 4, 2023, at 07:29, Christoph Hellwig wrote: > > On Thu, Mar 30, 2023 at 09:42:12PM +0100, Prabhakar wrote: > >> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > >> > >> Currently, selecting which CMOs to use on a given platform is done using > >> and ALTERNATIVE_X() macro. This was manageable when there were just two > >> CMO implementations, but now that there are more and more platforms coming > >> needing custom CMOs, the use of the ALTERNATIVE_X() macro is unmanageable. > >> > >> To avoid such issues this patch switches to use of function pointers > >> instead of ALTERNATIVE_X() macro for cache management (the only drawback > >> being performance over the previous approach). > >> > >> void (*clean_range)(unsigned long addr, unsigned long size); > >> void (*inv_range)(unsigned long addr, unsigned long size); > >> void (*flush_range)(unsigned long addr, unsigned long size); > >> > > > > NAK. Function pointers for somthing high performance as cache > > maintainance is a complete no-go. > > As we already discussed, this is now planned to use a direct > branch to the zicbom version when the function pointer is NULL, > which should be a fast predicted branch on all standard implementations > and only be slow on the nonstandard ones, which I think is a reasonable > compromise. > > I'm also not sure I'd actually consider this a fast path, since > there is already a significant cost in accessing the invalidated > cache lines afterwards, which is likely going to be much higher than > the cost of an indirect branch. > > I suppose an alternative would be to use the linux/static_call.h > infrastructure to avoid the overhead of indirect branches altogether. > Right now, this has no riscv specific implementation though, so > using it just turns into a regular indirect branch until someone > implements static_call. Someone actually posted an implementation for that the other day: https://patchwork.kernel.org/project/linux-riscv/patch/tencent_A8A256967B654625AEE1DB222514B0613B07@xxxxxx/ I haven't looked at it at all, other than noticing the build issues outside of for !rv64 || !mmu, so I have no idea what state it is actually in.
Attachment:
signature.asc
Description: PGP signature
