On Wed, Jun 24, 2020 at 1:23 PM Yang Shi <shy828301@xxxxxxxxx> wrote: > > On Wed, Jun 24, 2020 at 12:21 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > > On Wed, Jun 24, 2020 at 08:14:17PM +0100, Chris Wilson wrote: > > > A general rule of thumb is that shrinkers should be fast and effective. > > > They are called from direct reclaim at the most incovenient of times when > > > the caller is waiting for a page. If we attempt to reclaim a page being > > > pinned for active dma [pin_user_pages()], we will incur far greater > > > latency than a normal anonymous page mapped multiple times. Worse the > > > page may be in use indefinitely by the HW and unable to be reclaimed > > > in a timely manner. > > > > A pinned page can't be migrated, discarded or swapped by definition - > > it would cause data corruption. > > > > So, how do things even get here and/or work today at all? I think the > > explanation is missing something important. > > The __remove_mapping() will try to freeze page count if the count is > expected otherwise just not discard the page. I'm not quite sure why > the check is done that late, my wild guess is to check the refcount at > the last minute so there might be a chance the pin gets released right > before it. > > But I noticed a bug in __remove_ampping() for THP since THP's dma > pinned count is recorded in the tail page's hpage_pinned_refcount > instead of refcount. So, the refcount freeze might be successful for > pinned THP. Chris's patch could solve this issue too, but I'm not This bug is not valid. I just realized try_grab_page() would increase both refcount and hpage_pinned_refcount. > sure if it is worth backing earlier once dma pinned page is met. If it > is worth, the follow-up question is why not just skip such page in > scan phase? > > > > > Jason > >
