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 e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
