On Fri, Jan 31, 2020 at 07:40:25PM -0800, John Hubbard wrote: > For huge pages (and in fact, any compound page), the > GUP_PIN_COUNTING_BIAS scheme tends to overflow too easily, each tail > page increments the head page->_refcount by GUP_PIN_COUNTING_BIAS > (1024). That limits the number of huge pages that can be pinned. > > This patch removes that limitation, by using an exact form of pin > counting for compound pages of order > 1. The "order > 1" is required > because this approach uses the 3rd struct page in the compound page, and > order 1 compound pages only have two pages, so that won't work there. Could you update the comment for HPAGE_PMD_ORDER < 2 check in hugepage_init() to reflect addtional user for the condition. > > A new struct page field, hpage_pinned_refcount, has been added, > replacing a padding field in the union (so no new space is used). > > This enhancement also has a useful side effect: huge pages and compound > pages (of order > 1) do not suffer from the "potential false positives" > problem that is discussed in the page_dma_pinned() comment block. That > is because these compound pages have extra space for tracking things, so > they get exact pin counts instead of overloading page->_refcount. > > Documentation/core-api/pin_user_pages.rst is updated accordingly. > > Suggested-by: Jan Kara <jack@xxxxxxx> > Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx> Acked-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> -- Kirill A. Shutemov
