Received-SPF: pass (google.com: domain of linux-kernel+bounces-111728-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <tencent_6D851035F6F2FD0B5A69FB391AE39AC6300A@qq.com> <mhng-3e79924e-d965-4156-836d-19cc8fb8cafe@palmer-ri-x1c9a>
In-Reply-To: <mhng-3e79924e-d965-4156-836d-19cc8fb8cafe@palmer-ri-x1c9a>
From: Alexandre Ghiti <alexghiti@rivosinc.com>
Date: Fri, 22 Mar 2024 16:50:44 +0100
Message-ID: <CAHVXubiosOMnUghsaG_zDyX4wPQ3QGY_UhsUO+PGWQ8v2tDbFw@mail.gmail.com>
Subject: Re: [PATCH] RISC-V: only flush icache when it has VM_EXEC set
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: cyy@cyyself.name, linux-riscv@lists.infradead.org, 
	linux-kernel@vger.kernel.org, Paul Walmsley <paul.walmsley@sifive.com>, 
	aou@eecs.berkeley.edu, Conor Dooley <conor.dooley@microchip.com>, jszhang@kernel.org, 
	Andrew Waterman <andrew@sifive.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 1:48=E2=80=AFAM Palmer Dabbelt <palmer@dabbelt.com>=
 wrote:
>
> On Tue, 09 Jan 2024 10:48:59 PST (-0800), cyy@cyyself.name wrote:
> > As I-Cache flush on current RISC-V needs to send IPIs to every CPU core=
s
> > in the system is very costly, limiting flush_icache_mm to be called onl=
y
> > when vma->vm_flags has VM_EXEC can help minimize the frequency of these
> > operations. It improves performance and reduces disturbances when
> > copy_from_user_page is needed such as profiling with perf.
> >
> > For I-D coherence concerns, it will not fail if such a page adds VM_EXE=
C
> > flags in the future since we have checked it in the __set_pte_at functi=
on.
> >
> > Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> > ---
> >  arch/riscv/include/asm/cacheflush.h | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/a=
sm/cacheflush.h
> > index 3cb53c4df27c..915f532dc336 100644
> > --- a/arch/riscv/include/asm/cacheflush.h
> > +++ b/arch/riscv/include/asm/cacheflush.h
> > @@ -33,8 +33,11 @@ static inline void flush_dcache_page(struct page *pa=
ge)
> >   * so instead we just flush the whole thing.
> >   */
> >  #define flush_icache_range(start, end) flush_icache_all()
> > -#define flush_icache_user_page(vma, pg, addr, len) \
> > -     flush_icache_mm(vma->vm_mm, 0)
> > +#define flush_icache_user_page(vma, pg, addr, len)   \
> > +do {                                                 \
> > +     if (vma->vm_flags & VM_EXEC)                    \
> > +             flush_icache_mm(vma->vm_mm, 0);         \
> > +} while (0)
> >
> >  #ifdef CONFIG_64BIT
> >  #define flush_cache_vmap(start, end) flush_tlb_kernel_range(start, end=
)
>
> I'm not super worried about the benchmarks, I think we can just
> open-loop assume this is faster by avoiding the flushes.  I do think we
> need a hook into at least tlb_update_vma_flags(), though, to insert the
> fence.i when upgrading a mapping to include VM_EXEC.

I'd say Yangyu is right when he mentions in the commit log: "For I-D
coherence concerns, it will not fail if such a page adds VM_EXEC flags
in the future since we have checked it in the __set_pte_at function.".
If a region indeed becomes executable, the page table will be modified
to reflect that and then will pass in __set_pte_at() which, as Yangyu
mentions, does the right thing. Or am I missing something?

Thanks,

Alex