From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00D77C433DF for ; Thu, 25 Jun 2020 11:42:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B37682088E for ; Thu, 25 Jun 2020 11:42:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="IlAEIN73" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B37682088E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 517FD6B002C; Thu, 25 Jun 2020 07:42:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C8866B002D; Thu, 25 Jun 2020 07:42:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DECA6B002E; Thu, 25 Jun 2020 07:42:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id 24C8C6B002C for ; Thu, 25 Jun 2020 07:42:23 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C6927181AC9CB for ; Thu, 25 Jun 2020 11:42:22 +0000 (UTC) X-FDA: 76967546124.17.name49_520302726e4c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id A38EF180D0184 for ; Thu, 25 Jun 2020 11:42:22 +0000 (UTC) X-HE-Tag: name49_520302726e4c X-Filterd-Recvd-Size: 3127 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Thu, 25 Jun 2020 11:42:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fUle3aetxySRQYFTnbRVKd4H1XlZhjMbUYZWBlbn48k=; b=IlAEIN73y4SkxmCkWa7yhDlk/1 UTW+wamX8rd87nkcMA14xI0uj+0eOXBymR+brQ5VDMPdgCuIQj9fOIAD0VjGWzKJyTDEPLAij4+WQ VJJqHujQFBPr7JkgUDt+QAU0DthmowEChSj/NuZ8Hpy+1l07QSxDJFCZK6Dexf9pU6SNlVnyjs+5h yd3Qe0uKKMJzuqjIT5lWIA7tSJ01vemZ5QqyoOgreX9XHeczZitK58Q7GO1Gzdg1ykVg5Wj/BOWo+ 5GCmVrrXL7DZcbwuyEsdfVcVBmUhL5tzYpe/MMCEuWwnSPivhcofUheKgxN2SlgD9ZPx9FrKWdNb4 EBbP/zKA==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1joQGf-0002Qb-OE; Thu, 25 Jun 2020 11:42:09 +0000 Date: Thu, 25 Jun 2020 12:42:09 +0100 From: Matthew Wilcox To: Chris Wilson Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, Andrew Morton , Jan Kara , =?iso-8859-1?B?Suly9G1l?= Glisse , John Hubbard , Claudio Imbrenda , "Kirill A . Shutemov" , Jason Gunthorpe Subject: Re: [PATCH] mm: Skip opportunistic reclaim for dma pinned pages Message-ID: <20200625114209.GA7703@casper.infradead.org> References: <20200624191417.16735-1-chris@chris-wilson.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200624191417.16735-1-chris@chris-wilson.co.uk> X-Rspamd-Queue-Id: A38EF180D0184 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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: On Wed, Jun 24, 2020 at 08:14:17PM +0100, Chris Wilson wrote: > 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]. Why are DMA pinned pages still on the LRU list at all? I never got an answer to this that made sense to me. By definition, a page which is pinned for DMA is being accessed, and needs to at the very least change position on the LRU list, so just take it off the list when DMA-pinned and put it back on the list when DMA-unpinned. This overly complex lease stuff must have some reason for existing, but I still don't get it.