On Thu, Jan 26, 2017 at 02:57:52PM +0300, Kirill A. Shutemov wrote:
> @@ -405,9 +405,14 @@ static int __filemap_fdatawait_range(struct
> address_space *mapping,
> if (page->index > end)
> continue;
>
> + page = compound_head(page);
> wait_on_page_writeback(page);
> if (TestClearPageError(page))
> ret = -EIO;
> + if (PageTransHuge(page)) {
> + index = page->index + HPAGE_PMD_NR;
> + i += index - pvec.pages[i]->index - 1;
> + }
> }
I'm really not sure about your decision to have some interfaces expose
subpages and other expose huge pages. I think I'd be happier to see
all the existing interfaces made to continue exposing subpages, then
start adding in new interfaces and converting users one at a time
to use them. For example here, we'd add find_get_huge_pages_tag(),
then pagevec_lookup_huge_tag(), and switch this function from calling
pagevec_lookup_tag() to calling pagevec_lookup_huge_tag() ... then this
function is done; there's no messing around with calling compound_head
or PageTransHuge.
My dream is that eventually all callers will be able to cope with getting
a compound page back from the page cache and we can delete the versions
that return subpages, and rename the 'huge_' variations.
