Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp532069ybt; Wed, 24 Jun 2020 05:22:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxayDRy0n63k6Us93HgIE8MrUjpJVRIkpEDjY2inH6Qcir7r0NhEgProu+3fmjH+sDNZh0p X-Received: by 2002:a50:b8e3:: with SMTP id l90mr16238440ede.172.1593001337279; Wed, 24 Jun 2020 05:22:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593001337; cv=none; d=google.com; s=arc-20160816; b=QJrEIgmTp7j8wXch5dowikxwt3mQxEC7SZI/Kxz10FXARArghhMcmKZr+qFXeB8S2e rKhNs/ebvy4Hgy22vDVlgA9fGlzquC3dme2ATdXbYaXHOiuEOQEArNHg8DMDOaksK/Kd UxwoZHvD+v0a/JqwA1wN5NPtJBzrK8+OQ41f09plxvCR8s6QU7Iawhmivo59ix+/sJ0i xlZa3+OJn39SqYPlI5xb9SDxa2LDyvmiVrJ27F8jVqzy9vYc0+dCtBVNwkL8SyVm1ENb onDUozCzgcyVJKaYnf5Fxjiv4bA6wmfmDI82+eiVARQIuffmEojcer5DmQWzYhO8AXeG 7EPg== 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=+xVhWSiwn+G7SbFKKa8W4t9GrphEF61utrzmO6HcJNQ=; b=KVzoxJi/0JrnAbWoRiwkLK4ekC8m12DKNT4Xq8OkIu9R3Y9zXlDEUX4l5trPvBYvf9 rahoKVol2Uz8sV4WRvxd576HTvupBKjeWWe4wxJYw626dS2idpN8dW5+mEevb81m0lyf EVI4kvmUtuwbiK2LKrGGDiuH6OraQmA8kgbz3PKFK9NbHkA4dLCIqqEr9I9nMSaOZz1R K8/622KnfqrEnfiMoWTwxNkyT7e+TqGtOjLpv9aqVY7rUWHkEpbtLQJNY8MpPNBgNlFt dVjj33r0r3Op3KEoVcJj66SN+EmKkl5VKORnbwA3XUx4XIFCfPbGruUYpy8six6pAmc+ VegA== 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 p5si8486546edq.110.2020.06.24.05.21.53; Wed, 24 Jun 2020 05:22:17 -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 S2388718AbgFXMVQ convert rfc822-to-8bit (ORCPT + 99 others); Wed, 24 Jun 2020 08:21:16 -0400 Received: from mail.fireflyinternet.com ([109.228.58.192]:55174 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388548AbgFXMVN (ORCPT ); Wed, 24 Jun 2020 08:21:13 -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 21602377-1500050 for multiple; Wed, 24 Jun 2020 13:21:08 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT In-Reply-To: <20200624121053.GD6578@ziepe.ca> References: <20200624080248.3701-1-chris@chris-wilson.co.uk> <20200624121053.GD6578@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: <159300126338.4527.3968787379471939056@build.alporthouse.com> User-Agent: alot/0.8.1 Date: Wed, 24 Jun 2020 13:21:03 +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 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]. We're in the middle of allocating the object, how are we best to untangle that? Or during allocation of something that is using the pages pinned by that object, how are we best to not to shrink that object as there is a mutual dependency? -Chris