From: Ben Widawsky <ben@bwidawsk.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 05/18] drm/i915: context switch implementation
Date: Fri, 30 Mar 2012 11:11:46 -0700 [thread overview]
Message-ID: <20120330111146.02bb833b@bwidawsk.net> (raw)
In-Reply-To: <20120329184900.GC27737@phenom.ffwll.local>
On Thu, 29 Mar 2012 20:49:00 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Mar 29, 2012 at 11:43:12AM -0700, Ben Widawsky wrote:
> > On Thu, 29 Mar 2012 20:24:11 +0200
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > > On Sun, Mar 18, 2012 at 01:39:45PM -0700, Ben Widawsky wrote:
> > > > Implement the context switch code as well as the interfaces to do the
> > > > context switch. This patch also doesn't match 1:1 with the RFC patches.
> > > > The main difference is that from Daniel's responses the last context
> > > > object is now stored instead of the last context. This aids in allows us
> > > > to free the context data structure, and context object independently.
> > > >
> > > > There is room for optimization: this code will pin the context object
> > > > until the next context is active. The optimal way to do it is to
> > > > actually pin the object, move it to the active list, do the context
> > > > switch, and then unpin it. This allows the eviction code to actually
> > > > evict the context object if needed.
> > > >
> > > > The context switch code is missing workarounds, they will be implemented
> > > > in future patches.
> > > >
> > > > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > >
> > > Ok, I've looked at the use-sites of context_get and all this refcounting
> > > and noticed that:
> > > - we always hold dev->struct_mutex
> > > - we always drop the acquired reference to the context structure in the
> > > same function without dropping struct_mutex in between.
> > >
> > > So we don't seem to require any reference counting on these (and
> > > additional locking on the idr). Additionally the idr locking seems to give
> > > us a false sense of security because afaics the locking/refcounting would
> > > be broken when we would _not_ hold struct_mutex.
> > >
> > > So can we just rip this out or do we need this (in which case it needs
> > > some more work imo)?
> > > -Daniel
> >
> > I think it can be ripped out. I was on the fence about this before
> > submitting the patches and left it out of laziness; it doesn't hurt as
> > there is no lock contention assuming your statement is true with no
> > bugs in the code, and it follows the canonical use of idrs.
> >
> > Let me look it over some more to make sure after you finish reviewing
> > the other stuff. The idea was supposed to be contexts can be created
> > and looked up without struct mutex, but that isn't actually done in the
> > code.
>
> Well, if you want to leave it I have to add some more review comments
> about it - atm I think it would be buggy and racy without holding
> struct_mutex ...
> -Daniel
As I said before, I'll either find a good use for it, or remove it.
Context creation is the only currently viable case for it- but probably
not worth the extra lock.
next prev parent reply other threads:[~2012-03-30 18:11 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-18 20:39 [PATCH 00/18] i915 HW Context Support Ben Widawsky
2012-03-18 20:39 ` [PATCH 01/18] drm/i915: CXT_SIZE register offsets added Ben Widawsky
2012-03-18 20:39 ` [PATCH 02/18] drm/i915: preliminary context support Ben Widawsky
2012-03-28 22:43 ` Daniel Vetter
2012-03-28 22:59 ` Ben Widawsky
2012-03-29 8:43 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 03/18] drm/i915: context basic create & destroy Ben Widawsky
2012-03-18 20:39 ` [PATCH 04/18] drm/i915: add context information to objects Ben Widawsky
2012-03-28 22:36 ` Daniel Vetter
2012-03-29 0:20 ` Ben Widawsky
2012-03-29 8:47 ` Daniel Vetter
2012-03-29 15:57 ` Ben Widawsky
2012-03-18 20:39 ` [PATCH 05/18] drm/i915: context switch implementation Ben Widawsky
2012-03-29 18:24 ` Daniel Vetter
2012-03-29 18:43 ` Ben Widawsky
2012-03-29 18:49 ` Daniel Vetter
2012-03-30 18:11 ` Ben Widawsky [this message]
2012-03-29 18:47 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 06/18] drm/i915: trace events for contexts Ben Widawsky
2012-03-18 20:39 ` [PATCH 07/18] drm/i915: Ivybridge MI_ARB_ON_OFF context w/a Ben Widawsky
2012-03-18 20:39 ` [PATCH 08/18] drm/i915: PIPE_CONTROL_TLB_INVALIDATE Ben Widawsky
2012-03-18 20:39 ` [PATCH 09/18] drm/i915: possibly invalidate TLB before context switch Ben Widawsky
2012-03-29 19:25 ` Daniel Vetter
2012-03-30 18:39 ` Ben Widawsky
2012-03-30 19:01 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 10/18] drm/i915: use the default context Ben Widawsky
2012-03-18 20:39 ` [PATCH 11/18] drm/i915: switch to default context on idle Ben Widawsky
2012-03-29 19:29 ` Daniel Vetter
2012-03-29 20:28 ` Chris Wilson
2012-03-30 21:17 ` Ben Widawsky
2012-03-30 21:30 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 12/18] drm/i915: try to reset the gpu before unload Ben Widawsky
2012-03-29 19:31 ` Daniel Vetter
2012-03-30 18:50 ` Ben Widawsky
2012-03-30 19:05 ` Daniel Vetter
2012-03-30 16:54 ` Jesse Barnes
2012-03-30 17:30 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 13/18] drm/i915/context: create & destroy ioctls Ben Widawsky
2012-03-29 19:35 ` Daniel Vetter
2012-03-30 18:55 ` Ben Widawsky
2012-03-30 19:16 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 14/18] drm/i915/context: switch contexts with execbuf2 Ben Widawsky
2012-03-29 19:38 ` Daniel Vetter
2012-03-30 18:58 ` Ben Widawsky
2012-03-30 19:20 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 15/18] drm/i915/context: add params Ben Widawsky
2012-03-18 20:39 ` [PATCH 16/18] drm/i915/context: anonymous context interfaces Ben Widawsky
2012-03-29 19:42 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 17/18] drm/i915: Ironlake rc6 can use " Ben Widawsky
2012-03-29 19:47 ` Daniel Vetter
2012-03-18 20:39 ` [PATCH 18/18] drm/i915: try to enable rc6 on Ironlake... again Ben Widawsky
2012-03-19 3:47 ` [PATCH 00/18] i915 HW Context Support Ben Widawsky
2012-03-19 10:14 ` Daniel Vetter
2012-03-29 19:51 ` Daniel Vetter
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=20120330111146.02bb833b@bwidawsk.net \
--to=ben@bwidawsk.net \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox