From: Eric A. <er...@an...> - 2009-03-26 19:59:34
|
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 er...@an... eri...@in... |