Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp636339ybt; Wed, 24 Jun 2020 07:40:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDa3uRYDCMnOXTl0qqcfgRbA25ZAOtJW1ePC6P5WxIibCMH/loCpdNeFZOSRHXLq9nAX3P X-Received: by 2002:a17:906:b1c3:: with SMTP id bv3mr26159665ejb.292.1593009619182; Wed, 24 Jun 2020 07:40:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593009619; cv=none; d=google.com; s=arc-20160816; b=RwH+Se5zQjey0fQYXFyl+Je7bhItkaH3nQ2C61Fihod1n4BtBXUy1CtSwYFdFaJYpX L3o/hpJLCyObjlItHIFsjwPY2vdW+QuXp4ImkA1XWlpUT3mDJXjmJsKS/Ad0XNGAbk5S zCd87IQNtIW8lZgVsPMH0R6CVyTAIdZk5qXDf0E/d8WHqbTAet+YnXVXVvZR4/C6N29I 5lTFu8vu5q2maN9vhCw/HhoZu/0QQAFQGAiUpv49LsfRELK4zvwZjl8INNJyg2ETTmED /gf3G5i1QRXdqcmA9rbXyXSSJeuHORoM6Hgpao0t3TOaLwzl4nZGd8h6wm0TVwKon6Pm wO+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:user-agent:message-id:cc:to:subject :from:references:in-reply-to:content-transfer-encoding:mime-version; bh=DoAvrW9Gj9sMSKyzmzjrZzOOD8c06DqXLVowazv6AB4=; b=c+JoKGlFzF6BNK+io/OaeLr6QxYYgdpuXObvEivHfgt10BG7JeBhjnBygcdazNWTKs AEBhYi9L0oqIwElqlgbbvGcU0EGv8lawOSr8fbrAfDtdKjC7TpjFnUDWUT850AYqIAGJ WV3cjA8yoYisyo3tclQOscIswqytAWvUA4vbZeZeoFBkqJ9MkjpnVL3LWZtE4DbN6e3w YaIR2wtK/QDor2XuZMZMFuiKgdumCWfB3trK9zdJlKgXUzjmVl+GYlLNbSPbs1iAEbdK 6mrOD45LhoiMeu0tj3P13+aLC/AC0By1fNvC3cXwnKI6uAzZmOcNG5WyRASfqMAs+P3S 8nZw== ARC-Authentication-Results: i=1; mx.google.com; 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 k25si3717886ejv.672.2020.06.24.07.39.56; Wed, 24 Jun 2020 07:40:19 -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; 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 S2390981AbgFXOhl convert rfc822-to-8bit (ORCPT + 99 others); Wed, 24 Jun 2020 10:37:41 -0400 Received: from mail.fireflyinternet.com ([109.228.58.192]:59592 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388652AbgFXOhl (ORCPT ); Wed, 24 Jun 2020 10:37:41 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 21603863-1500050 for multiple; Wed, 24 Jun 2020 15:37:36 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT In-Reply-To: <20200624142544.GI6578@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> <20200624141604.GH6578@ziepe.ca> <159300850942.4527.8335506003268197914@build.alporthouse.com> <20200624142544.GI6578@ziepe.ca> From: Chris Wilson Subject: Re: [PATCH 1/2] mm/mmu_notifier: Mark up direct reclaim paths with MAYFAIL To: Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, Andrew Morton Message-ID: <159300945202.4527.4366416413140642633@build.alporthouse.com> User-Agent: alot/0.8.1 Date: Wed, 24 Jun 2020 15:37:32 +0100 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Jason Gunthorpe (2020-06-24 15:25:44) > On Wed, Jun 24, 2020 at 03:21:49PM +0100, Chris Wilson wrote: > > Quoting Jason Gunthorpe (2020-06-24 15:16:04) > > > 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. > > > > It's the shrinker being called while we are allocating for/on behalf of > > the object. As we are actively using the object, we don't want to free > > it -- the partial object allocation being the clearest, if the object > > consists of 2 pages, trying to free page 0 in order to allocate page 1 > > has to fail (and the shrinker should find another candidate to reclaim, > > or fail the allocation). > > mmu notifiers are not for influencing policy of the mm. It's policy is "this may fail" regardless of the mmu notifier at this point. That is not changed. Your suggestion is that we move the pages to the unevictable mapping so that the shrinker LRU is never invoked on pages we have grabbed with pin_user_page. Does that work with the rest of the mmu notifiers? -Chris