Thread (53 messages) 53 messages, 12 authors, 2014-09-25

Re: [PATCH 00/20] arch atomic 'cleanup'

From: Peter Zijlstra <peterz@infradead.org>
Date: 2014-09-24 18:06:32
Also in: lkml

On Wed, Sep 24, 2014 at 05:54:06PM +0100, Will Deacon wrote:
Hi Peter,

On Thu, May 08, 2014 at 02:58:40PM +0100, Peter Zijlstra wrote:
quoted
This series continues the arch atomic rework started with the smp_mb__
interface cleanup.

In this series we (mostly) reduce the atomic implementations by eliminating
repetition through use of CPP macros.

A future series will use these macros to implement more atomic ops. With these
macros we can end up with more atomic ops while the total LoC still shrinks.

Furthermore, rewrite the asm-generic/atomic implementations to require less and
provide more.

This series is compile tested on a number of archs, but only boot tested on
x86_64.
What's the status on this series? I'm currently fleshing out an extension to
the atomic API that allows more flexible acquire/release semantics and it
doesn't make sense for me to copy-paste a bunch of code when I could build
it on top of this instead.
Its in tip/locking/arch and I suppose its headed for the next merge
window.
Also, do you have any other patches pending in this area? I've lost track...
I do, I have (hopefully) one more series sweeping all archs introducing:
atomic_{or,and,xor,nand}() and then a few patches killing
atomic_{set,clear}_mask(). I just need to find time to write changelogs
and compile test them..

After that I need to go write that gcc-ll/sc proposal so we can pretend
to do generic composite atomic ops in C.

Oh, and like you pointed out, we need to do an audit of the barrier
semantics on some of our atomic functions like add_unless etc.

In other word, plenty to keep entertained.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help