Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp620732ybt; Wed, 24 Jun 2020 07:18:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7GL00PScKNhvRXbzj7ywoRKP5ZA6uDQcNNauIQkzQi+QmcxMDnoP8p43jbga3n5hSC/rb X-Received: by 2002:a17:906:c44c:: with SMTP id ck12mr7723761ejb.145.1593008319550; Wed, 24 Jun 2020 07:18:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593008319; cv=none; d=google.com; s=arc-20160816; b=A4cJMaEkPydn17kM4udqVW5Rp53Qe5oEXIKQ57rMuZvL1Ste32W0C0iI/sXDQDIZ9g J4DFqKqk1Ty/0MEwkk+zIAibGmtU9C7cW/Yjhjc7kVe0hVwm8t0Pq9YLVLdoa+1R+kwE LwXx1vbRRJc91nH6YPTiLSJ6gZ+30RBFmXnbx6isP1qL8EFDOpNB2K7+2j6nRt9Nqa00 PbNhh14cW3EiCtU364GZYWu/KTWqYlJaFM/SXopbB10WEi3IJezdE9ByftjDdsGEBvNV qMmtsMsp7hWFAnK6oMzv0lmPliDv8WkmK1FyKMqn8lxM0oRPTtZ1iMfLBkInJu9iLWo5 gMVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=XTCcXGeK3qAQaLUsGMJxhzPxremK361bquJrJgQE1cM=; b=WuurBuULtia3xJOzFaGG/Yg2iR+aBSS4cvDz2mmxVLMTylWcHbIp+GogmPUjsRalVI oQV98r+VUmEhPHQjGD0HOcasuGy2ou05FVrvEZicjAuHGbtC7gtHRJoaPEJ4kcGLz/LN Jdj1GjqZJrqxHXZW0NkGS9R+dtrTGtMiRfgr29vWr82I4gsTbobZbQPn5uZIoX35Ir20 /QMGTbRvyRZD1fQ2BaLVKl0sok29+s/ShKFs/8MTFiz0TL1lmfj2zr8iP1pKE10/F296 fO5hfk9mv4/oTu5X/TS8tw0IEyHDhYxJ2+u9uV95tXZwjouVLxsFrJiHea5uvcr0F547 sgEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=oSZInwNu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nx24si12437944ejb.615.2020.06.24.07.18.14; Wed, 24 Jun 2020 07:18:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=oSZInwNu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391168AbgFXOQH (ORCPT + 99 others); Wed, 24 Jun 2020 10:16:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389583AbgFXOQG (ORCPT ); Wed, 24 Jun 2020 10:16:06 -0400 Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC4A7C061573 for ; Wed, 24 Jun 2020 07:16:05 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id o38so1765923qtf.6 for ; Wed, 24 Jun 2020 07:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XTCcXGeK3qAQaLUsGMJxhzPxremK361bquJrJgQE1cM=; b=oSZInwNusWE97EVutQIRbsJeBwslSniUVMBcKNO5NzFS7QUontuAM2vj5hBHD3405f 8/T8VTo/2qNlvZ2mO8SqIxgrFiwgjfwtdJObthz+QUT21YDapCuMiaQjzpM8i3R/K2D6 V59F28UZQKm3pQxZiiguo1/NSuA2pV2/dBPu4jpU025NhlxFAypTeOFaHZnOiBoGOzAK jYUf+43UMVm+hYo50GLy/6b7ck9nYGi8syhkkTTa6r7J+nB8DUE+Vu8XsdZDuEMQ2NZO j689EkUzQ6ZL76x4cpO85iq+iACVRyJpNLylmnZNG0BABFBIUTTrPgIc0Gf+UGbOdOy7 sNzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XTCcXGeK3qAQaLUsGMJxhzPxremK361bquJrJgQE1cM=; b=MCJ2KPmiyg1pqlLLpxj8tr1VWnYcrjBDB0l6O8Yeer8HZxMR+f4sot5OPyUYUB2ld9 pVw2c+zrCI3voNcBCMVcE5zu6e+9P/DvC2mknCcZbambSQUHG9MsU/py7u8DjgeYZHl7 RpG6CklSTlRgszQDDCKPJLgdvghWo4WDlIBIHatK37DP+LWB9EKncYb2jxg+oP5ZjEwS RZexnzX79n5xufDFdM99bXCrb6Pb0tTZg+pt4LtDT7Fzjsxn/n7OtGmtKGsTs0P9yF/c n1FNxMdvFwrjCMeLCvVaKn8x26QnuchaY3esnj7m0iusVwvjnnRL39eS3BQVJ4xhNQog pg0Q== X-Gm-Message-State: AOAM532OvHPg2zMf7wH3Oh5XMmrwa9nZc95q5E+/tnUpWzo8bbEoXg1L 4M7bhskv1eqyB5fwSaaw1DOeaFV6qkFLNw== X-Received: by 2002:ac8:6f79:: with SMTP id u25mr27438038qtv.183.1593008165117; Wed, 24 Jun 2020 07:16:05 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id t9sm3479450qke.68.2020.06.24.07.16.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 07:16:04 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.93) (envelope-from ) id 1jo6C4-00DVi4-3z; Wed, 24 Jun 2020 11:16:04 -0300 Date: Wed, 24 Jun 2020 11:16:04 -0300 From: Jason Gunthorpe To: Chris Wilson Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, Andrew Morton Subject: Re: [PATCH 1/2] mm/mmu_notifier: Mark up direct reclaim paths with MAYFAIL Message-ID: <20200624141604.GH6578@ziepe.ca> References: <20200624080248.3701-1-chris@chris-wilson.co.uk> <20200624121053.GD6578@ziepe.ca> <159300126338.4527.3968787379471939056@build.alporthouse.com> <20200624123910.GA3178169@ziepe.ca> <159300796224.4527.2014771396582759689@build.alporthouse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159300796224.4527.2014771396582759689@build.alporthouse.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 24, 2020 at 03:12:42PM +0100, Chris Wilson wrote: > Quoting Jason Gunthorpe (2020-06-24 13:39:10) > > On Wed, Jun 24, 2020 at 01:21:03PM +0100, Chris Wilson wrote: > > > Quoting Jason Gunthorpe (2020-06-24 13:10:53) > > > > On Wed, Jun 24, 2020 at 09:02:47AM +0100, Chris Wilson wrote: > > > > > When direct reclaim enters the shrinker and tries to reclaim pages, it > > > > > has to opportunitically unmap them [try_to_unmap_one]. For direct > > > > > reclaim, the calling context is unknown and may include attempts to > > > > > unmap one page of a dma object while attempting to allocate more pages > > > > > for that object. Pass the information along that we are inside an > > > > > opportunistic unmap that can allow that page to remain referenced and > > > > > mapped, and let the callback opt in to avoiding a recursive wait. > > > > > > > > i915 should already not be holding locks shared with the notifiers > > > > across allocations that can trigger reclaim. This is already required > > > > to use notifiers correctly anyhow - why do we need something in the > > > > notifiers? > > > > > > for (n = 0; n < num_pages; n++) > > > pin_user_page() > > > > > > may call try_to_unmap_page from the lru shrinker for [0, n-1]. > > > > Yes, of course you can't hold any locks that intersect with notifiers > > across pin_user_page()/get_user_page() > > What lock though? It's just the page refcount, shrinker asks us to drop > it [via mmu], we reply we would like to keep using that page as freeing > it for the current allocation is "robbing Peter to pay Paul". Maybe I'm unclear what this series is actually trying to fix? You said "avoiding a recursive wait" which sounds like some locking deadlock to me. Still, again, notifiers are for tracking, not for influencing MM policy. Jason