On 11/28/2010 04:13 PM, Daniel Vetter wrote:
> Hi Thomas,
>
> On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
>
>> I'm not saying that the current gem code is incorrect. In
>> particular, the gem name system allows upping the handle_count even
>> if it's zero and the name is j
Hi Thomas,
On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
> I'm not saying that the current gem code is incorrect. In
> particular, the gem name system allows upping the handle_count even
> if it's zero and the name is just about to be destroyed. I see that
> more as a curiosity
On 11/28/2010 02:35 PM, Daniel Vetter wrote:
> On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
>
>> This is racy, in that the kref_get() can hit a zero refcount. I
>> think an ideal thing here would be to add a kref_get_unless_zero()
>> for this situation, that returns an erro
On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
> This is racy, in that the kref_get() can hit a zero refcount. I
> think an ideal thing here would be to add a kref_get_unless_zero()
> for this situation, that returns an error if the refcount was indeed
> zero. I don't think that
On 11/25/2010 11:38 PM, Dave Airlie wrote:
> On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
>
>> For a deferred-free cache of unreferenced bound objects, a simple
>> reference count is required without the baggage of kref.
>>
> eh?
>
> you've just out of lined kref for no real gai
On 11/28/2010 04:13 PM, Daniel Vetter wrote:
Hi Thomas,
On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
I'm not saying that the current gem code is incorrect. In
particular, the gem name system allows upping the handle_count even
if it's zero and the name is just about to
Hi Thomas,
On Sun, Nov 28, 2010 at 03:19:50PM +0100, Thomas Hellstrom wrote:
> I'm not saying that the current gem code is incorrect. In
> particular, the gem name system allows upping the handle_count even
> if it's zero and the name is just about to be destroyed. I see that
> more as a curiosity
On 11/28/2010 02:35 PM, Daniel Vetter wrote:
On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
This is racy, in that the kref_get() can hit a zero refcount. I
think an ideal thing here would be to add a kref_get_unless_zero()
for this situation, that returns an error if the r
On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote:
> This is racy, in that the kref_get() can hit a zero refcount. I
> think an ideal thing here would be to add a kref_get_unless_zero()
> for this situation, that returns an error if the refcount was indeed
> zero. I don't think that
On 11/25/2010 11:38 PM, Dave Airlie wrote:
On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
For a deferred-free cache of unreferenced bound objects, a simple
reference count is required without the baggage of kref.
eh?
you've just out of lined kref for no real gain.
the whole
On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
> For a deferred-free cache of unreferenced bound objects, a simple
> reference count is required without the baggage of kref.
eh?
you've just out of lined kref for no real gain.
the whole point of kref is that its standard and doesn't requi
> void kref_get(struct kref *kref)
> {
> WARN_ON(!atomic_read(&kref->refcount));
> atomic_inc(&kref->refcount);
> smp_mb__after_atomic_inc();
> }
>
> which causes havoc when you are trying to keep a list of unreferenced
> objects. That's all I'm trying to avoid.
You cannot
On Fri, 26 Nov 2010 08:38:29 +1000, Dave Airlie wrote:
> On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
> > For a deferred-free cache of unreferenced bound objects, a simple
> > reference count is required without the baggage of kref.
>
> eh?
The issue with kref is that it does:
void kr
For a deferred-free cache of unreferenced bound objects, a simple
reference count is required without the baggage of kref.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 12 +++-
drivers/gpu/drm/drm_info.c |2 +-
include/drm/drmP.h | 16 +---
3 f
> void kref_get(struct kref *kref)
> {
> WARN_ON(!atomic_read(&kref->refcount));
> atomic_inc(&kref->refcount);
> smp_mb__after_atomic_inc();
> }
>
> which causes havoc when you are trying to keep a list of unreferenced
> objects. That's all I'm trying to avoid.
You cannot
On Fri, 26 Nov 2010 08:38:29 +1000, Dave Airlie wrote:
> On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
> > For a deferred-free cache of unreferenced bound objects, a simple
> > reference count is required without the baggage of kref.
>
> eh?
The issue with kref is that it does:
void kr
On Thu, 2010-11-25 at 21:40 +, Chris Wilson wrote:
> For a deferred-free cache of unreferenced bound objects, a simple
> reference count is required without the baggage of kref.
eh?
you've just out of lined kref for no real gain.
the whole point of kref is that its standard and doesn't requi
For a deferred-free cache of unreferenced bound objects, a simple
reference count is required without the baggage of kref.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 12 +++-
drivers/gpu/drm/drm_info.c |2 +-
include/drm/drmP.h | 16 +---
3 f
18 matches
Mail list logo
