From patchwork Wed Jun 24 19:14:17 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Chris Wilson X-Patchwork-Id: 11624081 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 60B5C90 for ; Wed, 24 Jun 2020 19:14:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 37E3320702 for ; Wed, 24 Jun 2020 19:14:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37E3320702 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 357016B0008; Wed, 24 Jun 2020 15:14:56 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 2E0DB6B000A; Wed, 24 Jun 2020 15:14:56 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A9546B000C; Wed, 24 Jun 2020 15:14:56 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id F1D3D6B0008 for ; Wed, 24 Jun 2020 15:14:55 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 82E06824556B for ; Wed, 24 Jun 2020 19:14:55 +0000 (UTC) X-FDA: 76965057750.19.leg24_2712edd26e46 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 5A2601AD1B1 for ; Wed, 24 Jun 2020 19:14:55 +0000 (UTC) X-Spam-Summary: 1,0,0,dd74dcb265cd605c,d41d8cd98f00b204,chris@chris-wilson.co.uk,,RULES_HIT:41:152:355:379:541:800:960:966:973:988:989:1260:1277:1311:1313:1314:1345:1431:1437:1515:1516:1518:1534:1543:1593:1594:1711:1730:1747:1777:1792:2194:2196:2198:2199:2200:2201:2393:2553:2559:2562:2693:2731:2740:2901:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3872:3874:4031:4250:4385:5007:6119:6261:7903:8908:9108:10004:10400:10450:10455:11026:11232:11473:11658:11914:12043:12294:12297:12438:12555:12663:12895:13161:13229:13894:14181:14394:14571:14659:14721:14819:19904:19999:21080:21324:21451:21627:21740:21795:21990:30003:30051:30054:30064:30090,0,RBL:109.228.58.192:@chris-wilson.co.uk:.lbl8.mailshell.net-64.201.201.201 62.8.15.100;04y8aggge5p4ntqqrnkxmar1z598bocxd1k7erg68d7powbb5cfpq9nabmzwxeu.9bstnnx1nu8xpr9wx41gd531ccpi5819nr9ic1eh4kus33myghse4nma61iaxt4.k-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,M SBL:0,DN X-HE-Tag: leg24_2712edd26e46 X-Filterd-Recvd-Size: 4378 Received: from fireflyinternet.com (mail.fireflyinternet.com [109.228.58.192]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 24 Jun 2020 19:14:54 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from build.alporthouse.com (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP id 21606589-1500050 for multiple; Wed, 24 Jun 2020 20:14:22 +0100 From: Chris Wilson To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, Chris Wilson , Andrew Morton , Jan Kara , =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , John Hubbard , Claudio Imbrenda , "Kirill A . Shutemov" , Jason Gunthorpe Subject: [PATCH] mm: Skip opportunistic reclaim for dma pinned pages Date: Wed, 24 Jun 2020 20:14:17 +0100 Message-Id: <20200624191417.16735-1-chris@chris-wilson.co.uk> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 5A2601AD1B1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 side effect of the LRU shrinker not being dma aware is that we will often attempt to perform direct reclaim on the persistent group of dma pages while continuing to use the dma HW (an issue as the HW may already be actively waiting for the next user request), and even attempt to reclaim a partially allocated dma object in order to satisfy pinning the next user page for that object. It is to be expected that such pages are made available for reclaim at the end of the dma operation [unpin_user_pages()], and for truly longterm pins to be proactively recovered via device specific shrinkers [i.e. stop the HW, allow the pages to be returned to the system, and then compete again for the memory]. Signed-off-by: Chris Wilson Cc: Andrew Morton Cc: Jan Kara Cc: Jérôme Glisse Cc: John Hubbard Cc: Claudio Imbrenda Cc: Jan Kara Cc: Kirill A. Shutemov Cc: Jason Gunthorpe --- This seems perhaps a little devious and overzealous. Is there a more appropriate TTU flag? Would there be a way to limit its effect to say FOLL_LONGTERM? Doing the migration first would seem to be sensible if we disable opportunistic migration for the duration of the pin. --- mm/rmap.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/mm/rmap.c b/mm/rmap.c index 5fe2dedce1fc..374c6e65551b 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1393,6 +1393,22 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma, is_zone_device_page(page) && !is_device_private_page(page)) return true; + /* + * Try and fail early to revoke a costly DMA pinned page. + * + * Reclaiming an active DMA page requires stopping the hardware + * and flushing access. [Hardware that does support pagefaulting, + * and so can quickly revoke DMA pages at any time, does not need + * to pin the DMA page.] At worst, the page may be indefinitely in + * use by the hardware. Even at best it will take far longer to + * revoke the access via the mmu notifier, forcing that latency + * onto our callers rather than the consumer of the HW. As we are + * called during opportunistic direct reclaim, declare the + * opportunity cost too high and ignore the page. + */ + if (page_maybe_dma_pinned(page)) + return true; + if (flags & TTU_SPLIT_HUGE_PMD) { split_huge_pmd_address(vma, address, flags & TTU_SPLIT_FREEZE, page);