[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mhng-4e3e3fa7-5e25-494c-a3ad-6ef7ec78cf20@palmer-ri-x1c9a>
Date: Mon, 06 Nov 2023 23:00:03 -0800 (PST)
From: Palmer Dabbelt <palmer@...belt.com>
To: nadav.amit@...il.com
CC: alexghiti@...osinc.com, Will Deacon <will@...nel.org>,
aneesh.kumar@...ux.ibm.com, akpm@...ux-foundation.org,
npiggin@...il.com, peterz@...radead.org, mchitale@...tanamicro.com,
vincent.chen@...ive.com, Paul Walmsley <paul.walmsley@...ive.com>,
aou@...s.berkeley.edu, linux-arch@...r.kernel.org,
linux-mm@...ck.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, samuel@...lland.org,
prabhakar.csengg@...il.com
Subject: Re: [PATCH v6 0/4] riscv: tlb flush improvements
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.
> on the stack might cause it to be unaligned to
> the cacheline, which in x86 we have seen introduces some overhead.
We have 128-bit stack alignment on RISC-V, so the elements are at least
aligned. Since they're just being loaded up as scalars for the next
function call I'm not sure the alignment is all that exciting here.
> 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.
Powered by blists - more mailing lists