Re: [PATCH -next] tmpfs: fault in smaller chunks if large folio allocation not allowed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2024/9/15 18:40, Matthew Wilcox wrote:
On Sat, Sep 14, 2024 at 10:06:13PM +0800, Kefeng Wang wrote:
+++ b/mm/shmem.c
@@ -3228,6 +3228,7 @@ static ssize_t shmem_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
  {
  	struct file *file = iocb->ki_filp;
  	struct inode *inode = file->f_mapping->host;
+	pgoff_t index = iocb->ki_pos >> PAGE_SHIFT;
  	ssize_t ret;
inode_lock(inode);
@@ -3240,6 +3241,10 @@ static ssize_t shmem_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
  	ret = file_update_time(file);
  	if (ret)
  		goto unlock;
+
+	if (!shmem_allowable_huge_orders(inode, NULL, index, 0, false))
+		iocb->ki_flags |= IOCB_NO_LARGE_CHUNK;

Wouldn't it be better to call mapping_set_folio_order_range() so we
don't need this IOCB flag?


I think it before, but the comment of mapping_set_folio_order_range() said,

 "The filesystem should call this function in its inode constructor to
 indicate which base size (min) and maximum size (max) of folio the VFS
 can use to cache the contents of the file.  This should only be used
 if the filesystem needs special handling of folio sizes (ie there is
 something the core cannot know).
 Do not tune it based on, eg, i_size.

 Context: This should not be called while the inode is active as it
 is non-atomic."

and dynamically modify mappings without protect maybe a risk.

Or adding a new __generic_perform_write() with a chunk_size argument to
avoid to use a IOCB flag?




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux