All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: stable@vger.kernel.org, Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Subject: Re: [PATCH 2/2] drm/i915/gt: Schedule request retirement when timeline idles
Date: Mon, 30 Mar 2020 17:45:25 +0100	[thread overview]
Message-ID: <158558672536.3228.14244416875154195837@build.alporthouse.com> (raw)
In-Reply-To: <20200330163514.GA4184@sultan-box.localdomain>

Quoting Sultan Alsawaf (2020-03-30 17:35:14)
> On Mon, Mar 30, 2020 at 05:27:28PM +0100, Chris Wilson wrote:
> > Quoting Sultan Alsawaf (2020-03-30 04:30:57)
> > > +static void engine_retire(struct work_struct *work)
> > > +{
> > > +       struct intel_engine_cs *engine =
> > > +               container_of(work, typeof(*engine), retire_work);
> > > +       struct intel_timeline *tl = xchg(&engine->retire, NULL);
> > > +
> > > +       do {
> > > +               struct intel_timeline *next = xchg(&tl->retire, NULL);
> > > +
> > > +               /*
> > > +                * Our goal here is to retire _idle_ timelines as soon as
> > > +                * possible (as they are idle, we do not expect userspace
> > > +                * to be cleaning up anytime soon).
> > > +                *
> > > +                * If the timeline is currently locked, either it is being
> > > +                * retired elsewhere or about to be!
> > > +                */
> > 
> > iirc the backport requires the retirement to be wrapped in struct_mutex
> > 
> > mutex_lock(&engine->i915->drm.struct_mutex);
> > 
> > > +               if (mutex_trylock(&tl->mutex)) {
> > > +                       retire_requests(tl);
> > > +                       mutex_unlock(&tl->mutex);
> > > +               }
> > 
> > mutex_unlock(&engine->i915->drm.struct_mutex);
> > 
> > Now the question is whether that was for 5.3 or 5.4. I think 5.3 is
> > where the changes were more severe and where we switch to the 4.19
> > approach.
> > 
> > > +               intel_timeline_put(tl);
> > > +
> > > +               GEM_BUG_ON(!next);
> > > +               tl = ptr_mask_bits(next, 1);
> > > +       } while (tl);
> > > +}
> 
> In 5.4, the existing retirement instances don't hold
> `&engine->i915->drm.struct_mutex`, however it is held in 5.3. So it looks like
> this is fine as-is for 5.4.

git agrees.

commit e5dadff4b09376e8ed92ecc0c12f1b9b3b1fbd19
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 15 21:57:09 2019 +0100

    drm/i915: Protect request retirement with timeline->mutex

is in v5.4, so we should be safe to retire without the struct_mutex.
-Chris

  reply	other threads:[~2020-03-30 16:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30  3:30 [PATCH 0/2] A couple of important fixes for i915 on 5.4 Sultan Alsawaf
2020-03-30  3:30 ` [Intel-gfx] " Sultan Alsawaf
2020-03-30  3:30 ` Sultan Alsawaf
2020-03-30  3:30 ` [PATCH 1/2] drm/i915: Disable Panel Self Refresh (PSR) by default Sultan Alsawaf
2020-03-30  8:51   ` Greg KH
2020-03-30 15:50     ` Sultan Alsawaf
2020-03-30  3:30 ` [PATCH 2/2] drm/i915/gt: Schedule request retirement when timeline idles Sultan Alsawaf
2020-03-30  3:30   ` [Intel-gfx] " Sultan Alsawaf
2020-03-30  3:30   ` Sultan Alsawaf
2020-03-30 15:56   ` Sultan Alsawaf
2020-03-30 15:56     ` [Intel-gfx] " Sultan Alsawaf
2020-03-30 15:56     ` Sultan Alsawaf
2020-03-30 16:27   ` Chris Wilson
2020-03-30 16:35     ` Sultan Alsawaf
2020-03-30 16:45       ` Chris Wilson [this message]
2020-04-07 20:28         ` Sultan Alsawaf
2020-04-07 20:43           ` [PATCH v2] " Sultan Alsawaf
2020-04-12  7:48             ` Sultan Alsawaf
2020-04-12  7:56               ` Greg KH
2020-04-13 14:37                 ` Salvatore Bonaccorso
2020-04-13 15:23                 ` Sultan Alsawaf
2020-04-13 15:29                   ` [PATCH v3] " Sultan Alsawaf
2020-04-17  9:38                     ` Sultan Alsawaf
2020-04-18 10:29                       ` Greg KH
2020-04-18 10:30                     ` Greg KH
2020-03-30  8:51 ` [PATCH 0/2] A couple of important fixes for i915 on 5.4 Greg KH
2020-03-30 15:55   ` Sultan Alsawaf
2020-03-30 15:55     ` [Intel-gfx] " Sultan Alsawaf
2020-03-30 15:55     ` Sultan Alsawaf

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=158558672536.3228.14244416875154195837@build.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=sultan@kerneltoast.com \
    --cc=tvrtko.ursulin@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.