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=-1.0 required=3.0 tests=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 6F029C433DF for ; Wed, 24 Jun 2020 12:21:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3CD3720CC7 for ; Wed, 24 Jun 2020 12:21:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3CD3720CC7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A80186B0002; Wed, 24 Jun 2020 08:21:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A30546B0003; Wed, 24 Jun 2020 08:21:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 945106B0005; Wed, 24 Jun 2020 08:21:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id 7B0F26B0002 for ; Wed, 24 Jun 2020 08:21:19 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0BC451EE6 for ; Wed, 24 Jun 2020 12:21:19 +0000 (UTC) X-FDA: 76964015478.20.play30_2f171f126e44 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id CF1FD180C07AF for ; Wed, 24 Jun 2020 12:21:18 +0000 (UTC) X-HE-Tag: play30_2f171f126e44 X-Filterd-Recvd-Size: 2432 Received: from fireflyinternet.com (mail.fireflyinternet.com [109.228.58.192]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Wed, 24 Jun 2020 12:21:18 +0000 (UTC) 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: quoted-printable 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 X-Rspamd-Queue-Id: CF1FD180C07AF X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: 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. >=20 > 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 =3D 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