Dipankar Sarma wrote:
On Tue, Sep 13, 2005 at 12:51:01AM +1000, Nick Piggin wrote:
The recent file_table RCU work introduced a new rcuref.h thing,
which is just begging to be atomic.h. Basically it uses atomic_t,
digs into the atomic_t type, and also defines its own table of
spinlocks if the arch doesn't have cmpxchg() thus rendering it
unsafe for any other atomic_xxx operation to be performed on it.
The rcuref_xxx primitives were for only RCU protected refcounters
and I implemented all the primitives needed for them and use
of them was mandatory.
Oh yes, I realise that and I did not spot a bug in your implementation.
Anyway, as it turns out, my lockless pagecache patches have the
exact same requirement, and so I am proposing to implement two
new atomic_ primitives that should be useful.
Only one is actually needed, atomic_inc_not_zero being the exact
fit for both, however I did atomic_cmpxchg first and it can stay
around because hopefully will be a generally useful primitive.
Now atomic_inc_not_zero is not really anything to do with RCU other
than an RCU protected refcounted structure being an obvious user to
take a reference on the read side where there is nothing to pin it.
1/3 is atomic_cmpxchg, not guaranteed to even compile on most.
This is sooo much better. I would much rather kill rcuref.h
and directly use atomic_inc_not_zero() when necessary.
Please feel free to churn out the whole implementation and I will
test it.
OK, once I run it past the arch maintainers I will post a new set to
lkml (and cc you). If you are feeling brave, the atomic_cmpxchg on
ppc64 is working with my lockless pagecache patches, but I simply
haven't tested 3/3.
Anyway, please, arch maintainers: speak now if there is something
really nasty about doing this on your arch. Otherwise, if you can
cook up optimised versions then please send them to me. If not, I'll
try to do the dumb implementations as best I can.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
