The tmpfs could support large folio, but there is some configurable
options(mount options and runtime deny/force) to enable/disable large
folio allocation, so there is a performance issue when perform write
without large folio, the issue is similar to commit 4e527d5841e2
("iomap: fault in smaller chunks for non-large folio mappings").
Since 'deny' for emergencies and 'force' for testing, performence issue
should not be a problem in the real production environments, so only
don't call mapping_set_large_folios() in __shmem_get_inode() when
large folio is disabled with mount huge=never option(default policy).
Fixes: 9aac777aaf94 ("filemap: Convert generic_perform_write() to support large folios")
Signed-off-by: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
---
v4:
- only fix mount huge=never since runtime deny/force just for
emergencies/testing, suggested by Baolin
v3:
- don't enable large folio suppport in __shmem_get_inode() if disabled,
suggested by Matthew.
v2:
- Don't use IOCB flags
mm/shmem.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index e933327d8dac..74ef214dc1a7 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2827,7 +2827,10 @@ static struct inode *__shmem_get_inode(struct mnt_idmap *idmap,
cache_no_acl(inode);
if (sbinfo->noswap)
mapping_set_unevictable(inode->i_mapping);
- mapping_set_large_folios(inode->i_mapping);
+
+ /* Don't consider 'deny' for emergencies and 'force' for testing */
+ if (sbinfo->huge)
+ mapping_set_large_folios(inode->i_mapping);
switch (mode & S_IFMT) {
default:
--
2.27.0
