[v4,0/4] Svvptc extension to remove preventive sfence.vma

Message

Alexandre Ghiti July 17, 2024, 6:01 a.m. UTC

In RISC-V, after a new mapping is established, a sfence.vma needs to be
emitted for different reasons:

- if the uarch caches invalid entries, we need to invalidate it otherwise
  we would trap on this invalid entry,
- if the uarch does not cache invalid entries, a reordered access could fail
  to see the new mapping and then trap (sfence.vma acts as a fence).

We can actually avoid emitting those (mostly) useless and costly sfence.vma
by handling the traps instead:

- for new kernel mappings: only vmalloc mappings need to be taken care of,
  other new mapping are rare and already emit the required sfence.vma if
  needed.
  That must be achieved very early in the exception path as explained in
  patch 3, and this also fixes our fragile way of dealing with vmalloc faults.

- for new user mappings: Svvptc makes update_mmu_cache() a no-op but we can
  take some gratuitous page faults (which are very unlikely though).

Patch 1 and 2 introduce Svvptc extension probing.

On our uarch that does not cache invalid entries and a 6.5 kernel, the
gains are measurable:

* Kernel boot:                  6%
* ltp - mmapstress01:           8%
* lmbench - lat_pagefault:      20%
* lmbench - lat_mmap:           5%

Here are the corresponding numbers of sfence.vma emitted:

* Ubuntu boot to login:
Before: ~630k sfence.vma
After:  ~200k sfence.vma

* ltp - mmapstress01
Before: ~45k
After:  ~6.3k

* lmbench - lat_pagefault
Before: ~665k
After:   832 (!)

* lmbench - lat_mmap
Before: ~546k
After:   718 (!)

Thanks to Ved and Matt Evans for triggering the discussion that led to
this patchset!

Any feedback, test or relevant benchmark are welcome 

Comments

[e-mail] Sept. 17, 2024, 1 p.m. UTC | #1

Hello:

This series was applied to riscv/linux.git (for-next)
by Palmer Dabbelt <[e-mail]>:

On Wed, 17 Jul 2024 08:01:21 +0200 you wrote:
> In RISC-V, after a new mapping is established, a sfence.vma needs to be
> emitted for different reasons:
> 
> - if the uarch caches invalid entries, we need to invalidate it otherwise
>   we would trap on this invalid entry,
> - if the uarch does not cache invalid entries, a reordered access could fail
>   to see the new mapping and then trap (sfence.vma acts as a fence).
> 
> [...]

Here is the summary with links:
  - [v4,1/4] riscv: Add ISA extension parsing for Svvptc
    https://git.kernel.org/riscv/c/a6efe33cc594
  - [v4,2/4] dt-bindings: riscv: Add Svvptc ISA extension description
    https://git.kernel.org/riscv/c/d25599b5933f
  - [v4,3/4] riscv: Stop emitting preventive sfence.vma for new vmalloc mappings
    https://git.kernel.org/riscv/c/503638e0babf
  - [v4,4/4] riscv: Stop emitting preventive sfence.vma for new userspace mappings with Svvptc
    https://git.kernel.org/riscv/c/7a21b2e370da

You are awesome, thank you!