tmpfs: don't enable large folios if not supported#278
Open
GooTal wants to merge 1 commit into
Open
Conversation
|
开始测试 log: https://github.com/RVCK-Project/rvck/actions/runs/26032480947 参数解析结果
测试完成 详细结果:
Kunit Test Result[12:11:43] Testing complete. Ran 457 tests: passed: 445, skipped: 12
Kernel Build Result
Check Patch Result
|
GooTal
force-pushed
the
pr-huge-tmpfs-write-patch
branch
from
5cbe63c to
0433da3
Compare
|
开始测试 log: https://github.com/RVCK-Project/rvck/actions/runs/26032673541 参数解析结果
测试完成 详细结果:
Kunit Test Result[12:15:51] Testing complete. Ran 457 tests: passed: 445, skipped: 12
Kernel Build Result
Check Patch Result
|
fangyu0809
pushed a commit
to fangyu0809/rvck
that referenced
this pull request
May 20, 2026
[ Upstream commit 6435ffd ] When user resize all trace ring buffer through file 'buffer_size_kb', then in ring_buffer_resize(), kernel allocates buffer pages for each cpu in a loop. If the kernel preemption model is PREEMPT_NONE and there are many cpus and there are many buffer pages to be freed, it may not give up cpu for a long time and finally cause a softlockup. To avoid it, call cond_resched() after each cpu buffer free as Commit f6bd2c9 ("ring-buffer: Avoid softlockup in ring_buffer_resize()") does. Detailed call trace as follow: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 24-....: (14837 ticks this GP) idle=521c/1/0x4000000000000000 softirq=230597/230597 fqs=5329 rcu: (t=15004 jiffies g=26003221 q=211022 ncpus=96) CPU: 24 UID: 0 PID: 11253 Comm: bash Kdump: loaded Tainted: G EL 6.18.2+ RVCK-Project#278 NONE pc : arch_local_irq_restore+0x8/0x20 arch_local_irq_restore+0x8/0x20 (P) free_frozen_page_commit+0x28c/0x3b0 __free_frozen_pages+0x1c0/0x678 ___free_pages+0xc0/0xe0 free_pages+0x3c/0x50 ring_buffer_resize.part.0+0x6a8/0x880 ring_buffer_resize+0x3c/0x58 __tracing_resize_ring_buffer.part.0+0x34/0xd8 tracing_resize_ring_buffer+0x8c/0xd0 tracing_entries_write+0x74/0xd8 vfs_write+0xcc/0x288 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 Cc: <mathieu.desnoyers@efficios.com> Link: https://patch.msgid.link/20251228065008.2396573-1-mawupeng1@huawei.com Signed-off-by: Wupeng Ma <mawupeng1@huawei.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
mainline inclusion from mainline-v6.13-rc1 commit 5a90c15 category: bugfix Link: RVCK-Project#277 -------------------------------- The performance improvement of writing to tmpfs via fio becomes more significant as the block size increases. When the block size (BS) is small, the performance advantage isn't obvious and the data tends to fluctuate. However, with a larger BS, a clear advantage can still be observed even if there is some data fluctuation. Tested on qemu-system-riscv64, vcpu=1, mem=16G. Test command: 1.dd if=/dev/zero of=/mnt/tmpfs_test/test_file bs=1M count=1024 2.fio --name=seqwrite --filename=/mnt/test_file --rw=write --bs=?M \ --size=1G --direct=1 --numjobs=1 --time_based --runtime=30 \ --group_reporting ``` bs(MiB) Repetition before(MiB/s) after(MiB/s) improvement bs=2M 1 1077 1061 -1.49% 2 1170 1109 -5.21% 3 1106 1104 -0.18% 4 1101 1155 +4.90% bs=4M 1 1196 1132 -5.35% 2 1222 1092 -10.63% 3 1203 1200 -0.25% 4 1228 1445 +17.67% bs=8M 1 1406 1611 +14.58% 2 1278 1517 +22.93% 3 1484 1564 +5.39% 4 1503 1562 +3.93% bs=16M 1 1551 1656 +6.77% 2 1531 1638 +6.99% 3 1578 1671 +5.89% 4 1560 1603 +2.76% ``` original changelog tmpfs can support large folios, but there are some configurable options (mount options and runtime deny/force) to enable/disable large folio allocation, so there is a performance issue when performing writes without large folios. The issue is similar to commit 4e527d5 ("iomap: fault in smaller chunks for non-large folio mappings"). Since 'deny' is for emergencies and 'force' is for testing, performance issues should not be a problem in real production environments, so don't call mapping_set_large_folios() in __shmem_get_inode() when large folio is disabled with mount huge=never option (default policy). Link: https://lkml.kernel.org/r/20241017141742.1169404-1-wangkefeng.wang@huawei.com Fixes: 9aac777 ("filemap: Convert generic_perform_write() to support large folios") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Christian Brauner <brauner@kernel.org> Cc: David Hildenbrand <david@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jan Kara <jack@suse.cz> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Yang Susheng <yang.susheng@zte.com.cn> Signed-off-by: Liu Qingtao <liu.qingtao2@zte.com.cn>
GooTal
force-pushed
the
pr-huge-tmpfs-write-patch
branch
from
0433da3 to
8c0ac25
Compare
|
开始测试 log: https://github.com/RVCK-Project/rvck/actions/runs/26148931242 参数解析结果
|
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
2 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.
tmpfs: don't enable large folios if not supported
mainline inclusion
from mainline-v6.13-rc1
commit 5a90c15
category: bugfix
bugzilla: #277
Reference: torvalds/linux@5a90c15
The performance improvement of writing to tmpfs via fio becomes more significant as the block size increases. When the block size (BS) is small, the performance advantage isn't obvious and the data tends to fluctuate. However, with a larger BS, a clear advantage can still be observed even if there is some data fluctuation.
Tested on qemu-system-riscv64, vcpu=1, mem=16G.
Test command:
1.dd if=/dev/zero of=/mnt/tmpfs_test/test_file bs=1M count=1024 2.fio --name=seqwrite --filename=/mnt/test_file
--rw=write --bs=?M \ --size=1G --direct=1 --numjobs=1 --time_based --runtime=30 --group_reporting
original changelog
tmpfs: don't enable large folios if not supported
tmpfs can support large folios, but there are some configurable options (mount options and runtime deny/force) to enable/disable large folio allocation, so there is a performance issue when performing writes without large folios. The issue is similar to commit 4e527d5 ("iomap: fault in smaller chunks for non-large folio mappings").
Since 'deny' is for emergencies and 'force' is for testing, performance issues should not be a problem in real production environments, so don't call mapping_set_large_folios() in __shmem_get_inode() when large folio is disabled with mount huge=never option (default policy).
Link: https://lkml.kernel.org/r/20241017141742.1169404-1-wangkefeng.wang@huawei.com
Fixes: 9aac777 ("filemap: Convert generic_perform_write() to support large folios")
Cc: Alexander Viro viro@zeniv.linux.org.uk
Cc: Baolin Wang baolin.wang@linux.alibaba.com
Cc: Christian Brauner brauner@kernel.org
Cc: David Hildenbrand david@redhat.com
Cc: Hugh Dickins hughd@google.com
Cc: Jan Kara jack@suse.cz
Cc: Matthew Wilcox willy@infradead.org
Signed-off-by: Andrew Morton akpm@linux-foundation.org
Signed-off-by: Yang Susheng yang.susheng@zte.com.cn
Signed-off-by: Liu Qingtao liu.qingtao2@zte.com.cn