From: Nick Piggin <nickpiggin@yahoo.com.au>
To: dipankar@in.ibm.com
Cc: linux-arch@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 1/3][RFC] atomic_cmpxchg, atomic_inc_not_zero
Date: Tue, 13 Sep 2005 01:42:15 +1000 [thread overview]
Message-ID: <4325A1D7.103@yahoo.com.au> (raw)
In-Reply-To: <20050912153053.GA4778@in.ibm.com>
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
next prev parent reply other threads:[~2005-09-12 15:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-12 14:51 [PATCH 1/3][RFC] atomic_cmpxchg, atomic_inc_not_zero Nick Piggin
2005-09-12 14:53 ` [PATCH 2/3][RFC] " Nick Piggin
2005-09-12 14:55 ` [PATCH 3/3][RFC] remove rcuref.h Nick Piggin
2005-09-12 15:34 ` Dipankar Sarma
2005-09-12 15:30 ` [PATCH 1/3][RFC] atomic_cmpxchg, atomic_inc_not_zero Dipankar Sarma
2005-09-12 15:42 ` Nick Piggin [this message]
2005-09-12 16:11 ` Ralf Baechle
2005-09-12 20:46 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4325A1D7.103@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox