RFR: 8339771: RISC-V: Reduce icache flushes
Ludovic Henry
luhenry at openjdk.org
Tue Sep 10 07:30:05 UTC 2024
On Mon, 9 Sep 2024 12:33:01 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> Hey, please consider,
>
> All code which is offline (behind a barrier) do not need global icache flushes.
> As we can instead in slow path locally (thread and hart) emit fence.i.
> But if we were to be context switch do a hart which have not had fence.i emitted we can still fetch stale instructions.
> To handle this case new now have kernel support:
> https://docs.kernel.org/arch/riscv/cmodx.html
>
> It's not perfect as we will be emitting fence.i on any context switch for any thread with this patch, even if that thread do not execute on code heap (non attached native thread), and even if there was no changes to code heap.
> But this is in many cases much faster as the icache flush global IPI is very intrusive.
> Particular cases are running a concurrent gc with small head room.
> In such scenario I measured 15% increased throughput on VF2.
> A large CPU or less head room (faster GC cycles) will yield even more performance boost.
>
> Note that this requires 6.10 kernel.
>
> I'm running VF2 with 6.11-rc3 kernel and this passed tier1-3. (With setting on)
>
> Later we probably want this default on, but as it's hard to test I'll leave default off.
src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp line 126:
> 124: // Linux kernel require Zifencei
> 125: if (!ext_Zifencei.enabled()) {
> 126: ext_Zifencei.enable_feature();
That would deserve a `log_info` of sort, to make sure we can debug such state change in the wild
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20913#discussion_r1751410062
More information about the hotspot-dev
mailing list