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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 BE1FEC433E1 for ; Thu, 25 Jun 2020 13:40:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8D9EA20707 for ; Thu, 25 Jun 2020 13:40:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D9EA20707 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 057128D0006; Thu, 25 Jun 2020 09:40:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F23508D0002; Thu, 25 Jun 2020 09:40:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DED3B8D0006; Thu, 25 Jun 2020 09:40:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id C8D348D0002 for ; Thu, 25 Jun 2020 09:40:48 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 86F328245578 for ; Thu, 25 Jun 2020 13:40:48 +0000 (UTC) X-FDA: 76967844576.22.rail29_181544a26e4d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 47B5018037389 for ; Thu, 25 Jun 2020 13:40:48 +0000 (UTC) X-HE-Tag: rail29_181544a26e4d X-Filterd-Recvd-Size: 3271 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Thu, 25 Jun 2020 13:40:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E9490AEDD; Thu, 25 Jun 2020 13:40:44 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id E966C1E1274; Thu, 25 Jun 2020 15:40:44 +0200 (CEST) Date: Thu, 25 Jun 2020 15:40:44 +0200 From: Jan Kara To: Matthew Wilcox Cc: Chris Wilson , 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: <20200625134044.GD17788@quack2.suse.cz> References: <20200624191417.16735-1-chris@chris-wilson.co.uk> <20200625114209.GA7703@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200625114209.GA7703@casper.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 47B5018037389 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Thu 25-06-20 12:42:09, Matthew Wilcox wrote: > 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. Well, we do mark_page_accessed() when pinning in GUP. This is not perfect but it's as good as it gets with CPU having no control when the page is actually accessed. Also taking the page off and then back to LRU list would increase the contention on the LRU list locks and generally cost performance so for short term pins it is not desirable... Otherwise I agree that conceptually it would make some sence although I'm not sure some places wouldn't get confused by e.g. page cache pages not being on LRU list. Honza -- Jan Kara SUSE Labs, CR