From: "Arnd Bergmann" <arnd@arndb.de>
To: guoren <guoren@kernel.org>, "Heiko Stübner" <heiko@sntech.de>
Cc: "Emil Renner Berthing" <emil.renner.berthing@canonical.com>,
"Jisheng Zhang" <jszhang@kernel.org>,
Prabhakar <prabhakar.csengg@gmail.com>,
"Conor.Dooley" <conor.dooley@microchip.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"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,
"Christoph Hellwig" <hch@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 <linux-renesas-soc@vger.kernel.org>,
"Biju Das" <biju.das.jz@bp.renesas.com>,
"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH v10 3/6] riscv: mm: dma-noncoherent: nonstandard cache operations support
Date: Mon, 31 Jul 2023 07:39:30 +0200 [thread overview]
Message-ID: <8b3466e4-a295-4249-bd05-2edbf7b3f6e3@app.fastmail.com> (raw)
In-Reply-To: <CAJF2gTTRHzT+CEtb1LVYdfCorVUdLvCh_eMxrmC=xjdQ_JS6Sg@mail.gmail.com>
On Mon, Jul 31, 2023, at 02:49, Guo Ren wrote:
> On Mon, Jul 31, 2023 at 4:36 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Sun, Jul 30, 2023, at 17:42, Emil Renner Berthing wrote:
>> > On Sun, 30 Jul 2023 at 17:11, Jisheng Zhang <jszhang@kernel.org> wrote:
>>
>> >> > +
>> >> > static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
>> >> > {
>> >> > void *vaddr = phys_to_virt(paddr);
>> >> >
>> >> > +#ifdef CONFIG_RISCV_NONSTANDARD_CACHE_OPS
>> >> > + if (unlikely(noncoherent_cache_ops.wback)) {
>> >>
>> >> I'm worried about the performance impact here.
>> >> For unified kernel Image reason, RISCV_NONSTANDARD_CACHE_OPS will be
>> >> enabled by default, so standard CMO and T-HEAD's CMO platform's
>> >> performance will be impacted, because even an unlikely is put
>> >> here, the check action still needs to be done.
>> >
>> > On IRC I asked why not use a static key so the overhead is just a
>> > single nop when the standard CMO ops are available, but the consensus
>> > seemed to be that the flushing would completely dominate this branch.
>> > And on platforms with the standard CMO ops the branch be correctly
>> > predicted anyway.
>>
>> Not just the flushing, but also loading back the invalidated
>> cache lines afterwards is just very expensive. I don't think
>> you would be able to measure a difference between the static
>> key and a correctly predicted branch on any relevant usecase here.
> Maybe we should move CMO & THEAD ops to the noncoherent_cache_ops, and
> only keep one of them.
>
> I prefer noncoherent_cache_ops, it's more maintance than ALTERNATIVE.
I think moving the THEAD ops at the same level as all nonstandard
operations makes sense, but I'd still leave CMO as an explicit
fast path that avoids the indirect branch. This seems like the right
thing to do both for readability and for platforms on which the
indirect branch has a noticeable overhead.
Arnd
next prev parent reply other threads:[~2023-07-31 5:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-02 20:34 [PATCH v10 0/6] Add non-coherent DMA support for AX45MP Prabhakar
2023-07-02 20:34 ` [PATCH v10 1/6] riscv: asm: vendorid_list: Add Andes Technology to the vendors list Prabhakar
2023-07-02 20:34 ` [PATCH v10 2/6] riscv: errata: Add Andes alternative ports Prabhakar
2023-07-02 20:34 ` [PATCH v10 3/6] riscv: mm: dma-noncoherent: nonstandard cache operations support Prabhakar
2023-07-24 10:18 ` Emil Renner Berthing
2023-07-28 20:13 ` Lad, Prabhakar
2023-07-30 14:57 ` Jisheng Zhang
2023-07-30 15:42 ` Emil Renner Berthing
2023-07-30 20:35 ` Arnd Bergmann
2023-07-31 0:49 ` Guo Ren
2023-07-31 5:39 ` Arnd Bergmann [this message]
2023-07-31 15:43 ` Jisheng Zhang
2023-07-31 16:01 ` Arnd Bergmann
2023-07-31 11:30 ` Lad, Prabhakar
2023-07-31 11:38 ` Conor Dooley
2023-07-31 11:45 ` Lad, Prabhakar
2023-07-02 20:34 ` [PATCH v10 4/6] dt-bindings: cache: andestech,ax45mp-cache: Add DT binding documentation for L2 cache controller Prabhakar
2023-07-02 20:34 ` [PATCH v10 5/6] cache: Add L2 cache management for Andes AX45MP RISC-V core Prabhakar
2023-07-31 8:53 ` Emil Renner Berthing
2023-07-31 11:26 ` Lad, Prabhakar
2023-07-02 20:34 ` [PATCH v10 6/6] soc: renesas: Kconfig: Select the required configs for RZ/Five SoC Prabhakar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8b3466e4-a295-4249-bd05-2edbf7b3f6e3@app.fastmail.com \
--to=arnd@arndb.de \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=biju.das.jz@bp.renesas.com \
--cc=conor.dooley@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=emil.renner.berthing@canonical.com \
--cc=geert+renesas@glider.be \
--cc=guoren@kernel.org \
--cc=hch@infradead.org \
--cc=heiko@sntech.de \
--cc=jszhang@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=prabhakar.csengg@gmail.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).