[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1238097555.8275.55.camel@gaiman.anholt.net>
Date: Thu, 26 Mar 2009 12:59:15 -0700
From: Eric Anholt <eric@...olt.net>
To: Dave Airlie <airlied@...ux.ie>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.sourceforge.net
Subject: Re: [PATCH 2/6] drm/i915: Make GEM object's page lists refcounted
instead of get/free.
On Wed, 2009-03-25 at 22:52 +0000, Dave Airlie wrote:
> > We've wanted this for a few consumers that touch the pages directly (such as
> > the following commit), which have been doing the refcounting outside of
> > get/put pages.
>
> No idea if this is a valid point or not but whenever I see refcount that
> isn't a kref my internal, "should this be a kref" o-meter goes off.
All usage is under the struct mutex, since "get" is the transition from
0 -> 1 refcount, so I don't see how krefs would apply here (they're
suited more to refcounting objects after creation).
Our use of krefs for our GEM object refcounts is itself somewhat dubious
-- people have noted that we're spending a decent bit of CPU on the kref
usage, since the second hottest path is a loop of reffing objects (10-50
or so) up front, and loop of unreffing at the end. And when we're doing
that reffing, we're holding a spinlock on the table we're looking it up
from, anyway! So we end up with like 4 locked bus transactions per
object in exec that could easily be reduced to 2 total, if we made there
be a small "object referencing" lock covering the handle tables and
object refcounts.
--
Eric Anholt
eric@...olt.net eric.anholt@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists