Messages in this thread | | | Date | Tue, 3 Aug 2004 13:15:14 +0530 | From | Dipankar Sarma <> | Subject | Re: [patch] Add kref_read and kref_put_last primitives |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |