Messages in this thread | ![/](/images/icornerl.gif) | | From | Biju Das <> | Subject | RE: [PATCH v7 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management | Date | Tue, 4 Apr 2023 06:24:16 +0000 |
| |
Hi Christoph Hellwig,
> -----Original Message----- > From: Christoph Hellwig <hch@infradead.org> > Sent: Tuesday, April 4, 2023 6:29 AM > To: Prabhakar <prabhakar.csengg@gmail.com> > Cc: Arnd Bergmann <arnd@arndb.de>; Conor Dooley > <conor.dooley@microchip.com>; Geert Uytterhoeven <geert+renesas@glider.be>; > Heiko Stuebner <heiko@sntech.de>; Guo Ren <guoren@kernel.org>; Andrew Jones > <ajones@ventanamicro.com>; Paul Walmsley <paul.walmsley@sifive.com>; Palmer > Dabbelt <palmer@dabbelt.com>; Albert Ou <aou@eecs.berkeley.edu>; Samuel > Holland <samuel@sholland.org>; linux-riscv@lists.infradead.org; Rob Herring > <robh+dt@kernel.org>; Krzysztof Kozlowski > <krzysztof.kozlowski+dt@linaro.org>; devicetree@vger.kernel.org; linux- > kernel@vger.kernel.org; linux-renesas-soc@vger.kernel.org; Biju Das > <biju.das.jz@bp.renesas.com>; Prabhakar Mahadev Lad <prabhakar.mahadev- > lad.rj@bp.renesas.com> > Subject: Re: [PATCH v7 1/6] riscv: mm: dma-noncoherent: Switch using > function pointers for cache management > > On Thu, Mar 30, 2023 at 09:42:12PM +0100, Prabhakar wrote: > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > 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.
Just a question, how does function pointer makes a performance difference compared to ALTERNATIVE_X() macros?
On both cases, we are pushing function parameters to stack, jumping to the actual routine And then on return pop the variables from stack. Am I missing something here?
Benchmark results by [1], shows that there is no performance degradation. I am not sure What type of benchmarking used in this case and How accurate is this benchmark?
https://lore.kernel.org/linux-renesas-soc/40cdea465fef49a8a337b48e2a748138c66a08eb.camel@icenowy.me/T/#m093c1f3d8f7f0e15bd2909900bf137d5714c553c
Cheers, Biju
| ![\](/images/icornerr.gif) |