All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Ben Widawsky <ben@bwidawsk.net>,
	Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] drm/i915: Unpin stolen pages
Date: Sat, 1 Jun 2013 11:17:10 +0200	[thread overview]
Message-ID: <CAKMK7uGWS_q5fPbHaZ=x93VXi=V5194PgJTD8FNDhPPEZBRK-A@mail.gmail.com> (raw)
In-Reply-To: <20130531235102.GA1097@cantiga.alporthouse.com>

On Sat, Jun 1, 2013 at 1:51 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Fri, May 31, 2013 at 02:46:20PM -0700, Ben Widawsky wrote:
>> The way the stolen handling works is we take a pin on the backing pages,
>> but we never actually get a reference to the bo. On freeing objects
>> allocated with stolen memory, the final unref will end up freeing the
>> object with pinned pages count left. To enable an assertion to catch
>> bugs in this code path, this patch cleans up that remaining pin.
>>
>> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>
> That neatly explains the WARN. Not too happy about accumulating lots of
> backing storage specific processing into free_object, but that can be
> fixed up later (there is an obj->ops->release() pending).

I'm more irked with the semantic overloading of object pinning. Might
be cleaner to otherwise mark stolen obejcts as not shrinkable instead
of pinning them for their entire lifetime. But we can bikeshed that
later on ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2013-06-01  9:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-31 18:28 [PATCH 1/4] drm/i915: Demote unknown param to DRM_DEBUG Ben Widawsky
2013-05-31 18:28 ` [PATCH 2/4] drm/i915: Unbind the fb Ben Widawsky
2013-05-31 18:45   ` [PATCH 2/4] [v2] " Ben Widawsky
2013-05-31 19:39     ` Chris Wilson
2013-05-31 20:08       ` Ben Widawsky
2013-05-31 18:28 ` [PATCH 3/4] drm/i915: unpin pages at unbind Ben Widawsky
2013-05-31 18:46   ` Chris Wilson
2013-05-31 21:46     ` [PATCH 1/2] drm/i915: Make stolen use pin pages Ben Widawsky
2013-05-31 21:44       ` Ben Widawsky
2013-05-31 21:46       ` [PATCH 2/2] drm/i915: Unpin stolen pages Ben Widawsky
2013-05-31 23:51         ` Chris Wilson
2013-06-01  9:17           ` Daniel Vetter [this message]
2013-06-01 11:34             ` Chris Wilson
2013-06-01 13:13               ` Daniel Vetter
2013-06-03  8:36                 ` Chris Wilson
2013-06-03  8:52                   ` Daniel Vetter
2013-06-03 22:54                     ` Ben Widawsky
2013-05-31 18:28 ` [PATCH 4/4] drm/i915: Rename the gtt_list to global_list Ben Widawsky
2013-05-31 18:40   ` Chris Wilson
2013-05-31 18:38 ` [PATCH 1/4] drm/i915: Demote unknown param to DRM_DEBUG Chris Wilson

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='CAKMK7uGWS_q5fPbHaZ=x93VXi=V5194PgJTD8FNDhPPEZBRK-A@mail.gmail.com' \
    --to=daniel@ffwll.ch \
    --cc=ben@bwidawsk.net \
    --cc=chris@chris-wilson.co.uk \
    --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 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.