Backport subject : 'Svvptc extension to remove preventive sfence.vma'#105
Merged
sterling-teng merged 2 commits intoRVCK-Project:rvck-6.6from Sep 23, 2025
Merged
Backport subject : 'Svvptc extension to remove preventive sfence.vma'#105sterling-teng merged 2 commits intoRVCK-Project:rvck-6.6from
sterling-teng merged 2 commits intoRVCK-Project:rvck-6.6from
Conversation
|
开始测试 |
|
check patch done. log: https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/check-patch/140/consoleFull |
|
Kernel build success! |
|
kunit test done. log:https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/kunit-test/147/consoleFull |
|
Lava check done! result url: https://lava.oerv.ac.cn/results/520/0_rvck_common-test_qemu |
sterling-teng
force-pushed
the
rvck-6.6
branch
from
1cdcb55 to
bfade98
Compare
mainline inclusion from mainline-v6.11 commit 503638e category: feature bugzilla: RVCK-Project#104 ------------------------------- In 6.5, we removed the vmalloc fault path because that can't work (see [1] [2]). Then in order to make sure that new page table entries were seen by the page table walker, we had to preventively emit a sfence.vma on all harts [3] but this solution is very costly since it relies on IPI. And even there, we could end up in a loop of vmalloc faults if a vmalloc allocation is done in the IPI path (for example if it is traced, see [4]), which could result in a kernel stack overflow. Those preventive sfence.vma needed to be emitted because: - if the uarch caches invalid entries, the new mapping may not be observed by the page table walker and an invalidation may be needed. - if the uarch does not cache invalid entries, a reordered access could "miss" the new mapping and traps: in that case, we would actually only need to retry the access, no sfence.vma is required. So this patch removes those preventive sfence.vma and actually handles the possible (and unlikely) exceptions. And since the kernel stacks mappings lie in the vmalloc area, this handling must be done very early when the trap is taken, at the very beginning of handle_exception: this also rules out the vmalloc allocations in the fault path. Link: https://lore.kernel.org/linux-riscv/20230531093817.665799-1-bjorn@kernel.org/ [1] Link: https://lore.kernel.org/linux-riscv/20230801090927.2018653-1-dylan@andestech.com [2] Link: https://lore.kernel.org/linux-riscv/20230725132246.817726-1-alexghiti@rivosinc.com/ [3] Link: https://lore.kernel.org/lkml/20200508144043.13893-1-joro@8bytes.org/ [4] Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Yunhui Cui <cuiyunhui@bytedance.com> Link: https://lore.kernel.org/r/20240717060125.139416-4-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
… with Svvptc mainline inclusion from mainline-v6.11 commit 7a21b2e category: feature bugzilla: RVCK-Project#104 -------------------------------- The preventive sfence.vma were emitted because new mappings must be made visible to the page table walker but Svvptc guarantees that it will happen within a bounded timeframe, so no need to sfence.vma for the uarchs that implement this extension, we will then take gratuitous (but very unlikely) page faults, similarly to x86 and arm64. This allows to drastically reduce the number 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 (!) Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20240717060125.139416-5-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Gao Rui <gao.rui@zte.com.cn>
|
开始测试 |
|
Kernel build success! |
|
kunit test done. log:https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/kunit-test/158/consoleFull |
|
Lava check done! result url: https://lava.oerv.ac.cn/results/622/0_rvck_common-test_qemu |
|
check patch done. log: https://jenkins.oerv.ac.cn/job/rvck-pipeline/job/check-patch/164/consoleFull |
Contributor
|
补丁格式符合要求，代码移植无误，通过物理机测试后合并。 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
在 RISC-V 中，出于不同原因需要发出 sfence.vma来刷新tlb
实际上，我们可以通过Svvptc特性来避免发出这些（大多）无用且代价高昂的 sfence.vma，用来提升系统效率
测试方法，打开Svvptc特性，频繁创建vmalloc和用户进程，系统无异常发生