On 2024/9/30 10:52, Baolin Wang wrote:
On 2024/9/30 10:30, Kefeng Wang wrote:
On 2024/9/30 10:02, Baolin Wang wrote:
On 2024/9/26 21:52, Matthew Wilcox wrote:
On Thu, Sep 26, 2024 at 10:38:34AM +0200, Pankaj Raghav (Samsung)
wrote:
So this is why I don't use mapping_set_folio_order_range() here, but
correct me if I am wrong.
Yeah, the inode is active here as the max folio size is decided
based on
the write size, so probably mapping_set_folio_order_range() will
not be
a safe option.
You really are all making too much of this. Here's the patch I
think we
need:
+++ b/mm/shmem.c
@@ -2831,7 +2831,8 @@ 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);
+ if (sbinfo->huge)
+ mapping_set_large_folios(inode->i_mapping);
switch (mode & S_IFMT) {
default:
IMHO, we no longer need the the 'sbinfo->huge' validation after
adding support for large folios in the tmpfs write and fallocate
paths [1].
Forget to mention, we still need to check sbinfo->huge, if mount with
huge=never, but we fault in large chunk, write is slower than without
9aac777aaf94, the above changes or my patch could fix it.
Kefeng, can you try if the following RFC patch [1] can solve your
problem? Thanks.
(PS: I will revise the patch according to Matthew's suggestion)
Sure, will try once I come back, but [1] won't solve the issue when set
Cool. Thanks.
force/deny at runtime, eg, mount with always/within_size, but set deny
when runtime, we still fault in large chunks, but we can't allocate
large folio, the performance of write will be degradation.
Yes, but as Hugh mentioned before, the options 'force' and 'deny' are
rather testing artifacts from the old ages. So I suspect if the 'deny'
option will be set in the real products, that means do we really need
consider this case too much?
OK, so maybe just update the document.
