Re: Direct I/O performance problems with 1GB pages

[Matthew Wilcox <willy@infradead.org>]

On Mon, Jan 27, 2025 at 05:20:25PM +0100, David Hildenbrand wrote:
> > >       14.04%  postgres         [kernel.kallsyms]          [k] try_grab_folio_fast
> > >               |
> > >                --14.04%--try_grab_folio_fast
> > >                          gup_fast_fallback
> > >                          |
> > >                           --13.85%--iov_iter_extract_pages
> > >                                     bio_iov_iter_get_pages
> > >                                     iomap_dio_bio_iter
> > >                                     __iomap_dio_rw
> > >                                     iomap_dio_rw
> > >                                     xfs_file_dio_read
> > >                                     xfs_file_read_iter
> > >                                     __io_read
> > >                                     io_read
> > >                                     io_issue_sqe
> > >                                     io_submit_sqes
> > >                                     __do_sys_io_uring_enter
> > >                                     do_syscall_64
> 
> BTW, two things that come to mind:
> 
> 
> (1) We always fallback to GUP-slow, I wonder why. GUP-fast would go via
> try_grab_folio_fast().

I don't think we do?

iov_iter_extract_pages() calls
iov_iter_extract_user_pages() calls
pin_user_pages_fast() calls
gup_fast_fallback() calls
gup_fast() calls
gup_fast_pgd_range() calls
gup_fast_p4d_range() calls
gup_fast_pud_range() calls
gup_fast_pud_leaf() calls
try_grab_folio_fast() which is where we see the contention.

If that were to fail, we'd see contention in __get_user_pages_locked(),
right?