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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>