linux-kernel - Re: [PATCH 2/6] drm/i915: Make GEM object's page lists refcounted instead of get/free.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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)