Received-SPF: pass (google.com: domain of linux-kernel+bounces-112346-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <tencent_BE1AABF8C6052FB4FD1DD9713962E0425609@qq.com>
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Subject: Re: [PATCH] RISC-V: only flush icache when it has VM_EXEC set
From: Yangyu Chen <cyy@cyyself.name>
In-Reply-To: <CAHVXubiosOMnUghsaG_zDyX4wPQ3QGY_UhsUO+PGWQ8v2tDbFw@mail.gmail.com>
Date: Sat, 23 Mar 2024 20:39:21 +0800
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
 linux-riscv@lists.infradead.org,
 linux-kernel@vger.kernel.org,
 Paul Walmsley <paul.walmsley@sifive.com>,
 Albert Ou <aou@eecs.berkeley.edu>,
 Conor Dooley <conor.dooley@microchip.com>,
 jszhang@kernel.org,
 Andrew Waterman <andrew@sifive.com>
Content-Transfer-Encoding: quoted-printable
References: <tencent_6D851035F6F2FD0B5A69FB391AE39AC6300A@qq.com>
 <mhng-3e79924e-d965-4156-836d-19cc8fb8cafe@palmer-ri-x1c9a>
 <CAHVXubiosOMnUghsaG_zDyX4wPQ3QGY_UhsUO+PGWQ8v2tDbFw@mail.gmail.com>
To: Alexandre Ghiti <alexghiti@rivosinc.com>


> On Mar 22, 2024, at 23:50, Alexandre Ghiti <alexghiti@rivosinc.com> =
wrote:
>=20
> On Wed, Mar 20, 2024 at 1:48=E2=80=AFAM Palmer Dabbelt =
<palmer@dabbelt.com> wrote:
>>=20
>> 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 =
cores
>>> in the system is very costly, limiting flush_icache_mm to be called =
only
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>> ---
>>> arch/riscv/include/asm/cacheflush.h | 7 +++++--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>=20
>>> diff --git a/arch/riscv/include/asm/cacheflush.h =
b/arch/riscv/include/asm/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 =
*page)
>>>  * 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)
>>>=20
>>> #ifdef CONFIG_64BIT
>>> #define flush_cache_vmap(start, end) flush_tlb_kernel_range(start, =
end)
>>=20
>> 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.
>=20
> 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?
>=20

I think so. Unless we have any other way to update PTE rather than
using __set_pte_at, I think it=E2=80=99s safe. I=E2=80=99m too busy =
these days to
provide a micro enough benchmark.

Thanks,
Yangyu Chen