linux-kernel - Re: [PATCH v6 0/4] riscv: tlb flush improvements

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: <D1DBDDD4-9B6A-40EA-993E-FF6CF02A2668@gmail.com>
Date:   Tue, 7 Nov 2023 10:38:01 +0200
From:   Nadav Amit <nadav.amit@...il.com>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Alexandre Ghiti <alexghiti@...osinc.com>,
        Will Deacon <will@...nel.org>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nick Piggin <npiggin@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Mayuresh Chitale <mchitale@...tanamicro.com>,
        Vincent Chen <vincent.chen@...ive.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>, linux-arch@...r.kernel.org,
        linux-mm <linux-mm@...ck.org>, linux-riscv@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Samuel Holland <samuel@...lland.org>,
        Lad Prabhakar <prabhakar.csengg@...il.com>
Subject: Re: [PATCH v6 0/4] riscv: tlb flush improvements



> On Nov 7, 2023, at 9:00 AM, Palmer Dabbelt <palmer@...belt.com> wrote:
> 
> On Mon, 30 Oct 2023 07:01:48 PDT (-0700), nadav.amit@...il.com wrote:
>> 
>>> On Oct 30, 2023, at 3:30 PM, Alexandre Ghiti <alexghiti@...osinc.com> wrote:
>>> + on_each_cpu_mask(cmask,
>>> + __ipi_flush_tlb_range_asid,
>>> + &ftd, 1);
>> 
>> Unrelated, but having fed
> 
> Do you mean `ftd`?
> 
> If so I'm not all that convinced that's a problem: sure it's 4x`long`, so we pass it on the stack instead of registers, but otherwise we'd need another `on_each_cpu_mask()` callback to shim stuff through via registers.

I have no idea why you need to move stuff through the registers.

>> Actually, it is best not to put it on the stack, if possible to reduce
>> cache traffic.
> 
> Sorry if I'm just missing something, but I'm not convinced this is a measurable performance problem.

I am not going to try to convince you (I ran the numbers on x86 a long
time ago).

There is a cost of bouncing cache-lines (because multiple cores access
the stack), TLB-miss on remote cores (which is mostly avoidable if ftd
is global).

Having said that, the optimizations you added now and intend to add in
the next steps are definitely more important for performance.