Why filemap_read() in mm/filemap.c uses folio_batch(pagevec)?
by jhbaik from LinuxQuestions.org on (#6QVFG)
I'm modifying the filemap_read() function in mm/filemap.c and I'm trying to understand why it uses folio_batch (or pagevec) to manage pages. Is it because this data structure is already available and provides a convenient way to keep pages together, or is there another reason?
Also, these data structures are limited to PAGEVEC_SIZE which is 15 ( after v6.9 it changed to 31), and I've seen discussions about using larger sizes in the past (e.g., 512 pages - https://lore.kernel.org/all/20201104...infradead.org/ ) or just seemed to use without pagevec data structures before. Based on this mail(https://lore.kernel.org/all/20201105...infradead.org/) , it seems that it's because of increasing the size does not significantly improve performance, as the time spent in memcpy dominates the time spent traversing the radix tree for page cache.
Can someone provide more insight into the design choice behind using folio_batch or pagevec in filemap_read()?
Also, these data structures are limited to PAGEVEC_SIZE which is 15 ( after v6.9 it changed to 31), and I've seen discussions about using larger sizes in the past (e.g., 512 pages - https://lore.kernel.org/all/20201104...infradead.org/ ) or just seemed to use without pagevec data structures before. Based on this mail(https://lore.kernel.org/all/20201105...infradead.org/) , it seems that it's because of increasing the size does not significantly improve performance, as the time spent in memcpy dominates the time spent traversing the radix tree for page cache.
Can someone provide more insight into the design choice behind using folio_batch or pagevec in filemap_read()?