| Message ID | 20170126115819.58875-11-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
diff --git a/mm/filemap.c b/mm/filemap.c index 4e398d5e4134..f5cd654b3662 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -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; + } } pagevec_release(&pvec); cond_resched();
We writeback whole huge page a time. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> --- mm/filemap.c | 5 +++++ 1 file changed, 5 insertions(+)