Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1578026
| From | Matthew Wilcox <willy@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCHv6 10/37] filemap: handle huge pages in filemap_fdatawait_range() |
| Date | 2017-02-10 00:10 +0100 |
| Message-ID | <t960G-3Z2-29@gated-at.bofh.it> (permalink) |
| References | <t3QSB-6QS-5@gated-at.bofh.it> <t3R2i-79n-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [PATCHv6 10/37] filemap: handle huge pages in filemap_fdatawait_range() Matthew Wilcox <willy@infradead.org> - 2017-02-10 00:10 +0100
csiph-web