From: Jason Gunthorpe <jgg@ziepe.ca>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] mm/mmu_notifier: Mark up direct reclaim paths with MAYFAIL
Date: Wed, 24 Jun 2020 09:10:53 -0300 [thread overview]
Message-ID: <20200624121053.GD6578@ziepe.ca> (raw)
In-Reply-To: <20200624080248.3701-1-chris@chris-wilson.co.uk>
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?
I really don't like this patch, the purpose of notifiers is only to
*track changes* not to influence policy of the callers.
Jason
next prev parent reply other threads:[~2020-06-24 12:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-24 8:02 [Intel-gfx] [PATCH 1/2] mm/mmu_notifier: Mark up direct reclaim paths with MAYFAIL Chris Wilson
2020-06-24 8:02 ` Chris Wilson
2020-06-24 8:02 ` [Intel-gfx] [PATCH 2/2] drm/i915/gem: Use mmu_notifier_range_mayfail() to avoid waiting inside reclaim Chris Wilson
2020-06-24 8:02 ` Chris Wilson
2020-06-24 11:34 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] mm/mmu_notifier: Mark up direct reclaim paths with MAYFAIL Patchwork
2020-06-24 11:54 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-06-24 12:10 ` Jason Gunthorpe [this message]
2020-06-24 12:21 ` [Intel-gfx] [PATCH 1/2] " Chris Wilson
2020-06-24 12:21 ` Chris Wilson
2020-06-24 12:39 ` Jason Gunthorpe
2020-06-24 14:12 ` [Intel-gfx] " Chris Wilson
2020-06-24 14:12 ` Chris Wilson
2020-06-24 14:16 ` Jason Gunthorpe
2020-06-24 14:21 ` [Intel-gfx] " Chris Wilson
2020-06-24 14:21 ` Chris Wilson
2020-06-24 14:25 ` Jason Gunthorpe
2020-06-24 14:37 ` [Intel-gfx] " Chris Wilson
2020-06-24 14:37 ` Chris Wilson
2020-06-24 16:50 ` Jason Gunthorpe
2020-06-24 17:58 ` [Intel-gfx] " Chris Wilson
2020-06-24 17:58 ` Chris Wilson
2020-06-24 18:48 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200624121053.GD6578@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.