From: "Goel, Akash" <akash.goel@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org, Hugh Dickins <hughd@google.com>,
linux-mm@kvack.org
Cc: Sourab Gupta <sourab.gupta@intel.com>, akash.goel@intel.com
Subject: Re: [PATCH 2/2] drm/i915: Make pages of GFX allocations movable
Date: Wed, 23 Mar 2016 13:55:14 +0530 [thread overview]
Message-ID: <56F252EA.1020600@intel.com> (raw)
In-Reply-To: <20160323075809.GA21952@nuc-i3427.alporthouse.com>
On 3/23/2016 1:28 PM, Chris Wilson wrote:
> On Wed, Mar 23, 2016 at 11:39:44AM +0530, akash.goel@intel.com wrote:
>> +#ifdef CONFIG_MIGRATION
>> +static int i915_migratepage(struct address_space *mapping,
>> + struct page *newpage, struct page *page,
>> + enum migrate_mode mode, void *dev_priv_data)
>
> If we move this to i915_gem_shrink_migratepage (i.e. i915_gem_shrink),
> we can
>
>> + /*
>> + * Use trylock here, with a timeout, for struct_mutex as
>> + * otherwise there is a possibility of deadlock due to lock
>> + * inversion. This path, which tries to migrate a particular
>> + * page after locking that page, can race with a path which
>> + * truncate/purge pages of the corresponding object (after
>> + * acquiring struct_mutex). Since page truncation will also
>> + * try to lock the page, a scenario of deadlock can arise.
>> + */
>> + while (!mutex_trylock(&dev->struct_mutex) && --timeout)
>> + schedule_timeout_killable(1);
>
> replace this with i915_gem_shrinker_lock() and like constructs with the
> other shrinkers.
fine, will rename the function to gem_shrink_migratepage, move it inside
the gem_shrinker.c file, and use the existing constructs.
> Any reason for dropping the early
> if (!page_private(obj)) skip?
>
Would this sequence be fine ?
if (!page_private(page))
goto migrate; /*skip */
Loop for locking mutex
obj = (struct drm_i915_gem_object *)page_private(page);
if (!PageSwapCache(page) && obj) {
> Similarly there are other patterns here that would benefit from
> integration with existing shrinker logic. However, things like tidying
> up the pin_display, unbinding, rpm lock inversion are still only on
> list.
Tidying, like split that one single if condition into multiple if, else
if blocks ?
Best regards
Akash
> -Chris
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-03-23 8:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 6:09 [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops akash.goel
2016-03-23 6:09 ` [PATCH 2/2] drm/i915: Make pages of GFX allocations movable akash.goel
2016-03-23 7:58 ` Chris Wilson
2016-03-23 8:25 ` Goel, Akash [this message]
2016-03-24 8:13 ` Chris Wilson
2016-03-24 18:22 ` [PATCH v2 " akash.goel
2016-03-24 18:22 ` akash.goel
2016-03-24 18:40 ` Chris Wilson
2016-04-04 11:27 ` [PATCH v3 " akash.goel
2016-04-04 11:27 ` akash.goel
2016-03-23 7:39 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops Patchwork
2016-03-24 12:11 ` [PATCH 1/2] " Joonas Lahtinen
2016-03-24 12:11 ` [Intel-gfx] " Joonas Lahtinen
2016-10-19 15:11 ` akash goel
2016-10-19 15:11 ` [Intel-gfx] " akash goel
2016-10-20 15:15 ` Joonas Lahtinen
2016-10-20 15:15 ` [Intel-gfx] " Joonas Lahtinen
2016-11-04 12:48 ` [PATCH 1/2] shmem: Support for registration of driver/file " akash.goel
2016-11-04 12:48 ` [PATCH 2/2] drm/i915: Make GPU pages movable akash.goel
2016-11-04 13:37 ` Chris Wilson
2016-11-04 13:37 ` Chris Wilson
2016-11-04 13:53 ` Goel, Akash
2016-03-25 7:31 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops (rev2) Patchwork
2016-04-04 13:14 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops (rev3) Patchwork
2016-11-04 13:31 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] shmem: Support for registration of driver/file owner specific ops (rev4) Patchwork
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=56F252EA.1020600@intel.com \
--to=akash.goel@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-mm@kvack.org \
--cc=sourab.gupta@intel.com \
/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.