From: Chris Wilson <chris@chris-wilson.co.uk>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/selftests: Pretty print the i915_active
Date: Thu, 31 Oct 2019 14:33:05 +0000 [thread overview]
Message-ID: <157253238555.11954.9104169948286950027@skylake-alporthouse-com> (raw)
In-Reply-To: <157253153647.11954.14804810030906563091@skylake-alporthouse-com>
Quoting Chris Wilson (2019-10-31 14:18:56)
> My memory says, and my assumption in this code, is that the
> the iterator is safe against insertions -- we won't get horribly lost if
> the tree is rebalanced as we walk.
Actually, the iterator is not perfect across rebalances. It won't matter
here in the selftest, since we are the only accessor, the two other
users deserve throught.
In __active_retire, we have exclusive access to the tree as we are
freeing the nodes. Safe.
In i915_active_wait() [we can't take the mutex here due to shrinker
inversions!], we walk the tree to kick signaling on the nodes. So the
iterator is not perfect, but calling enable_signaling() is mostly an
optimisation so that we don't have to wait upon the background flush. So
I think we are safe to miss nodes, so long as the iterator itself is
bounded (which it must be).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/selftests: Pretty print the i915_active
Date: Thu, 31 Oct 2019 14:33:05 +0000 [thread overview]
Message-ID: <157253238555.11954.9104169948286950027@skylake-alporthouse-com> (raw)
Message-ID: <20191031143305.LA-e9yo5HaK7cKMgfH4CVOUWqLldl9ZJ01ZJ9rvPuZg@z> (raw)
In-Reply-To: <157253153647.11954.14804810030906563091@skylake-alporthouse-com>
Quoting Chris Wilson (2019-10-31 14:18:56)
> My memory says, and my assumption in this code, is that the
> the iterator is safe against insertions -- we won't get horribly lost if
> the tree is rebalanced as we walk.
Actually, the iterator is not perfect across rebalances. It won't matter
here in the selftest, since we are the only accessor, the two other
users deserve throught.
In __active_retire, we have exclusive access to the tree as we are
freeing the nodes. Safe.
In i915_active_wait() [we can't take the mutex here due to shrinker
inversions!], we walk the tree to kick signaling on the nodes. So the
iterator is not perfect, but calling enable_signaling() is mostly an
optimisation so that we don't have to wait upon the background flush. So
I think we are safe to miss nodes, so long as the iterator itself is
bounded (which it must be).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-10-31 14:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-31 10:02 [PATCH] drm/i915/selftests: Pretty print the i915_active Chris Wilson
2019-10-31 10:02 ` [Intel-gfx] " Chris Wilson
2019-10-31 10:11 ` Chris Wilson
2019-10-31 10:11 ` [Intel-gfx] " Chris Wilson
2019-10-31 14:11 ` Mika Kuoppala
2019-10-31 14:11 ` [Intel-gfx] " Mika Kuoppala
2019-10-31 14:18 ` Chris Wilson
2019-10-31 14:18 ` [Intel-gfx] " Chris Wilson
2019-10-31 14:33 ` Chris Wilson [this message]
2019-10-31 14:33 ` Chris Wilson
2019-10-31 14:34 ` Mika Kuoppala
2019-10-31 14:34 ` [Intel-gfx] " Mika Kuoppala
2019-10-31 10:58 ` ✓ Fi.CI.BAT: success for drm/i915/selftests: Pretty print the i915_active (rev2) Patchwork
2019-10-31 10:58 ` [Intel-gfx] " Patchwork
2019-11-01 11:05 ` ✓ Fi.CI.IGT: " Patchwork
2019-11-01 11:05 ` [Intel-gfx] " 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=157253238555.11954.9104169948286950027@skylake-alporthouse-com \
--to=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mika.kuoppala@linux.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.