Re: [patch] Add kref_read and kref_put_last primitives

[Dipankar Sarma]

On Mon, Aug 02, 2004 at 11:51:30PM -0700, Greg KH wrote:
> On Tue, Aug 03, 2004 at 11:12:18AM +0530, Dipankar Sarma wrote:
> 
> > So, kref_read() as it is would look weird. But if we consider merging
> > the rest of the kref APIs (lock-free extensions) in future, then the
> > entire set including kref_read() would make sense.
> 
> No, even with rcu versions, I don't see the need for this in the api.

I agree that RCU versions really doesn't need it. However, there
is code in many places in the kernel where we actually read
the actual reference count value and even compare it with
constants. Those things are problematic because you can't
use kref there without a kref_read_count() type API.
In typical driver object maintenance, this is not an issue
and rightly not exported.

> Sure, for this specific implementation of a atomic_t, it is useful, as
> the value is checked.  But that means that you might just want to use an
> atomic_t, as it doesn't fit the model of a struct kref at all (something
> where you don't touch the reference count directly at all.)

Which prevents it from being used in many objects where we touch
the reference count directly. If we use atomic_t there, then we
need to abstract out inc/dec for RCU, which results in another
refcounter which you don't like (for good reasons, btw) ;-) 

> Becides, I don't think that people are convinced that this code needs to
> be changed anyway :)

Which code ? If you are talking about the lock-free fd lookup
code, think POSIX threaded apps doing lots of I/O. tiobench
results show how useful it is.

Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/