linux-kernel - Re: [PATCH v10 3/6] riscv: mm: dma-noncoherent: nonstandard cache operations support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <dd614e72-dc04-4dd1-b2c8-b16166c3c21b@app.fastmail.com>
Date:   Mon, 31 Jul 2023 18:01:13 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Jisheng Zhang" <jszhang@...nel.org>
Cc:     guoren <guoren@...nel.org>,
        Heiko Stübner <heiko@...ech.de>,
        "Emil Renner Berthing" <emil.renner.berthing@...onical.com>,
        Prabhakar <prabhakar.csengg@...il.com>,
        "Conor.Dooley" <conor.dooley@...rochip.com>,
        "Geert Uytterhoeven" <geert+renesas@...der.be>,
        "Andrew Jones" <ajones@...tanamicro.com>,
        "Paul Walmsley" <paul.walmsley@...ive.com>,
        "Palmer Dabbelt" <palmer@...belt.com>,
        "Albert Ou" <aou@...s.berkeley.edu>,
        "Samuel Holland" <samuel@...lland.org>,
        linux-riscv@...ts.infradead.org,
        "Christoph Hellwig" <hch@...radead.org>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "Biju Das" <biju.das.jz@...renesas.com>,
        "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v10 3/6] riscv: mm: dma-noncoherent: nonstandard cache operations
 support

On Mon, Jul 31, 2023, at 17:43, Jisheng Zhang wrote:
> On Mon, Jul 31, 2023 at 07:39:30AM +0200, Arnd Bergmann wrote:

>> >> 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
>
> I read this as: the cache clean/inv is so expensive that the static
> key saving percentage is trivial, is this understanding right?
>
> this could be measured by writing a small benchmark kernel module
> which just calls cache clean/inv a buf(for example 1500Bytes)in a loop. 

While you can trivially measure the cost of the clean/inv operation,
I think the higher cost is the fact that the cache lines are
invalidated and have to be reloaded when accessing the data the next
time. So if the loop test shows that the static key is not worth
it, that is a clear answer, but if it shows that the cache operation
itself is cheap, that does not automatically mean that the
static key makes a difference compared to a cache miss.

     Arnd