Re: [PATCH v2] iomap: avoid redundant fault_in_iov_iter_readable() judgement when use larger chunks

[Matthew Wilcox <willy@infradead.org>]

On Sat, May 18, 2024 at 04:14:07AM +0800, Xu Yang wrote:
> Since commit (5d8edfb900d5 "iomap: Copy larger chunks from userspace"),
> iomap will try to copy in larger chunks than PAGE_SIZE. However, if the
> mapping doesn't support large folio, only one page of maximum 4KB will
> be created and 4KB data will be writen to pagecache each time. Then,
> next 4KB will be handled in next iteration.
> 
> If chunk is 2MB, total 512 pages need to be handled finally. During this
> period, fault_in_iov_iter_readable() is called to check iov_iter readable
> validity. Since only 4KB will be handled each time, below address space
> will be checked over and over again:
> 
> start         	end
> -
> buf,    	buf+2MB
> buf+4KB, 	buf+2MB
> buf+8KB, 	buf+2MB
> ...
> buf+2044KB 	buf+2MB
> 
> Obviously the checking size is wrong since only 4KB will be handled each
> time. So this will get a correct bytes before fault_in_iov_iter_readable()
> to let iomap work well in non-large folio case.

You haven't talked at all about why this is important.  Is it a
performance problem?  If so, numbers please.  Particularly if you want
this backported to stable.

I alos think this is the wrong way to solve the problem.  We should
instead adjust 'chunk'.  Given everything else going on, I think we
want:

(in filemap.h):

static inline size_t mapping_max_folio_size(struct address_space *mapping)
{
	if (mapping_large_folio_support(mapping))
		return PAGE_SIZE << MAX_PAGECACHE_ORDER;
	return PAGE_SIZE;
}

and then in iomap,

-	size_t chunk = PAGE_SIZE << MAX_PAGECACHE_ORDER;
+	size_t chunk = mapping_max_folio_size(mapping);

(and move the initialisation of 'mapping' to before this)