Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Sun, Dec 27, 2015 at 06:53:39PM +1100, Michael Ellerman wrote: > On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote: > > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > > Hi all, > > > > > > > > This is v6 of the series. > > > > > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > > > > > > > Changes since v5: > > > > > > > > * rebase on the next branch of powerpc. > > > > > > > > * pull two fix and one testcase patches out, which are already > > > > sent separately > > > > > > > > * some clean up or code format fixing. > > > > > > > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in > > > > the review > > > > of previous versions. From this version on, This series is against the > > > > next > > > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > > > > > > > Sorry if we already discussed this, but did we decide how we were going to > > > merge this? There's the one patch to generic code and then three powerpc > > > patches. > > > > > > It'd make most sense for it to go via powerpc I think. Given that the > > > change to > > > generic code is relatively trivial I'll plan to merge this unless someone > > > objects. > > > > > > Also it is pretty late in the -next cycle for something like this. But > > > AFAICS > > > there are no users of these "atomic*relaxed" variants yet other than > > > arm64 code > > > and qspinlocks, neither of which are used on powerpc. So adding them > > > should be > > > pretty harmless. > > > > > > > There is one thing we should be aware of, that is the bug: > > > > http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com > > > > which though has been fixed by: > > > > http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net > > > > but the fix is not in powerpc/next right now. As this patchset makes > > atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if > > this series gets merged in the next branch of powerpc tree, though > > that's not the problem of this patchset. > > > > Not sure whether this is a problem for your maintence, but just think > > it's better to make you aware of this ;-) > > Yes that's pretty important thank you :) > > It's not so much that bug that's important, but the fact that I completely > forget about the acquire/release implementations. Those are used already in > mainline and so we don't want to add implementations this late in the cycle > without wider testing. > Understood. > So I'll have to push this series until 4.6 so it can get some time in -next. > Sorry! > That's fine, thank you! Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Sun, Dec 27, 2015 at 06:53:39PM +1100, Michael Ellerman wrote: > On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote: > > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > > Hi all, > > > > > > > > This is v6 of the series. > > > > > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > > > > > > > Changes since v5: > > > > > > > > * rebase on the next branch of powerpc. > > > > > > > > * pull two fix and one testcase patches out, which are already > > > > sent separately > > > > > > > > * some clean up or code format fixing. > > > > > > > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in > > > > the review > > > > of previous versions. From this version on, This series is against the > > > > next > > > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > > > > > > > Sorry if we already discussed this, but did we decide how we were going to > > > merge this? There's the one patch to generic code and then three powerpc > > > patches. > > > > > > It'd make most sense for it to go via powerpc I think. Given that the > > > change to > > > generic code is relatively trivial I'll plan to merge this unless someone > > > objects. > > > > > > Also it is pretty late in the -next cycle for something like this. But > > > AFAICS > > > there are no users of these "atomic*relaxed" variants yet other than > > > arm64 code > > > and qspinlocks, neither of which are used on powerpc. So adding them > > > should be > > > pretty harmless. > > > > > > > There is one thing we should be aware of, that is the bug: > > > > http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com > > > > which though has been fixed by: > > > > http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net > > > > but the fix is not in powerpc/next right now. As this patchset makes > > atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if > > this series gets merged in the next branch of powerpc tree, though > > that's not the problem of this patchset. > > > > Not sure whether this is a problem for your maintence, but just think > > it's better to make you aware of this ;-) > > Yes that's pretty important thank you :) > > It's not so much that bug that's important, but the fact that I completely > forget about the acquire/release implementations. Those are used already in > mainline and so we don't want to add implementations this late in the cycle > without wider testing. > Understood. > So I'll have to push this series until 4.6 so it can get some time in -next. > Sorry! > That's fine, thank you! Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote: > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > > > This is v6 of the series. > > > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > > > > Changes since v5: > > > > > > * rebase on the next branch of powerpc. > > > > > > * pull two fix and one testcase patches out, which are already > > > sent separately > > > > > > * some clean up or code format fixing. > > > > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in the > > > review > > > of previous versions. From this version on, This series is against the > > > next > > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > > > > Sorry if we already discussed this, but did we decide how we were going to > > merge this? There's the one patch to generic code and then three powerpc > > patches. > > > > It'd make most sense for it to go via powerpc I think. Given that the > > change to > > generic code is relatively trivial I'll plan to merge this unless someone > > objects. > > > > Also it is pretty late in the -next cycle for something like this. But > > AFAICS > > there are no users of these "atomic*relaxed" variants yet other than arm64 > > code > > and qspinlocks, neither of which are used on powerpc. So adding them should > > be > > pretty harmless. > > > > There is one thing we should be aware of, that is the bug: > > http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com > > which though has been fixed by: > > http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net > > but the fix is not in powerpc/next right now. As this patchset makes > atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if > this series gets merged in the next branch of powerpc tree, though > that's not the problem of this patchset. > > Not sure whether this is a problem for your maintence, but just think > it's better to make you aware of this ;-) Yes that's pretty important thank you :) It's not so much that bug that's important, but the fact that I completely forget about the acquire/release implementations. Those are used already in mainline and so we don't want to add implementations this late in the cycle without wider testing. So I'll have to push this series until 4.6 so it can get some time in -next. Sorry! cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote: > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > > > This is v6 of the series. > > > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > > > > Changes since v5: > > > > > > * rebase on the next branch of powerpc. > > > > > > * pull two fix and one testcase patches out, which are already > > > sent separately > > > > > > * some clean up or code format fixing. > > > > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in the > > > review > > > of previous versions. From this version on, This series is against the > > > next > > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > > > > Sorry if we already discussed this, but did we decide how we were going to > > merge this? There's the one patch to generic code and then three powerpc > > patches. > > > > It'd make most sense for it to go via powerpc I think. Given that the > > change to > > generic code is relatively trivial I'll plan to merge this unless someone > > objects. > > > > Also it is pretty late in the -next cycle for something like this. But > > AFAICS > > there are no users of these "atomic*relaxed" variants yet other than arm64 > > code > > and qspinlocks, neither of which are used on powerpc. So adding them should > > be > > pretty harmless. > > > > There is one thing we should be aware of, that is the bug: > > http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com > > which though has been fixed by: > > http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net > > but the fix is not in powerpc/next right now. As this patchset makes > atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if > this series gets merged in the next branch of powerpc tree, though > that's not the problem of this patchset. > > Not sure whether this is a problem for your maintence, but just think > it's better to make you aware of this ;-) Yes that's pretty important thank you :) It's not so much that bug that's important, but the fact that I completely forget about the acquire/release implementations. Those are used already in mainline and so we don't want to add implementations this late in the cycle without wider testing. So I'll have to push this series until 4.6 so it can get some time in -next. Sorry! cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, 23 Dec 2015, Boqun Feng wrote: There is one thing we should be aware of, that is the bug: http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com which though has been fixed by: http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net Right, and fwiw the testing I did included this fix. signature.asc Description: Digital signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > This is v6 of the series. > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > Changes since v5: > > > > * rebase on the next branch of powerpc. > > > > * pull two fix and one testcase patches out, which are already > > sent separately > > > > * some clean up or code format fixing. > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in the > > review > > of previous versions. From this version on, This series is against the next > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > Sorry if we already discussed this, but did we decide how we were going to > merge this? There's the one patch to generic code and then three powerpc > patches. > > It'd make most sense for it to go via powerpc I think. Given that the change > to > generic code is relatively trivial I'll plan to merge this unless someone > objects. > > Also it is pretty late in the -next cycle for something like this. But AFAICS > there are no users of these "atomic*relaxed" variants yet other than arm64 > code > and qspinlocks, neither of which are used on powerpc. So adding them should be > pretty harmless. > There is one thing we should be aware of, that is the bug: http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com which though has been fixed by: http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net but the fix is not in powerpc/next right now. As this patchset makes atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if this series gets merged in the next branch of powerpc tree, though that's not the problem of this patchset. Not sure whether this is a problem for your maintence, but just think it's better to make you aware of this ;-) Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, 23 Dec 2015, Boqun Feng wrote: There is one thing we should be aware of, that is the bug: http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com which though has been fixed by: http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net Right, and fwiw the testing I did included this fix. signature.asc Description: Digital signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > This is v6 of the series. > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > Changes since v5: > > > > * rebase on the next branch of powerpc. > > > > * pull two fix and one testcase patches out, which are already > > sent separately > > > > * some clean up or code format fixing. > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in the > > review > > of previous versions. From this version on, This series is against the next > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > Sorry if we already discussed this, but did we decide how we were going to > merge this? There's the one patch to generic code and then three powerpc > patches. > > It'd make most sense for it to go via powerpc I think. Given that the change > to > generic code is relatively trivial I'll plan to merge this unless someone > objects. > > Also it is pretty late in the -next cycle for something like this. But AFAICS > there are no users of these "atomic*relaxed" variants yet other than arm64 > code > and qspinlocks, neither of which are used on powerpc. So adding them should be > pretty harmless. > There is one thing we should be aware of, that is the bug: http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com which though has been fixed by: http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net but the fix is not in powerpc/next right now. As this patchset makes atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if this series gets merged in the next branch of powerpc tree, though that's not the problem of this patchset. Not sure whether this is a problem for your maintence, but just think it's better to make you aware of this ;-) Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > This is v6 of the series. > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > Changes since v5: > > > > * rebase on the next branch of powerpc. > > > > * pull two fix and one testcase patches out, which are already > > sent separately > > > > * some clean up or code format fixing. > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in the > > review > > of previous versions. From this version on, This series is against the next > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > Sorry if we already discussed this, but did we decide how we were going to > merge this? There's the one patch to generic code and then three powerpc > patches. > We might have "discussed" this ;-) As I proposed this would go to the powerpc next in this mail: http://marc.info/?l=linux-kernel=144660021417639=2 Regards, Boqun > It'd make most sense for it to go via powerpc I think. Given that the change > to > generic code is relatively trivial I'll plan to merge this unless someone > objects. > > Also it is pretty late in the -next cycle for something like this. But AFAICS > there are no users of these "atomic*relaxed" variants yet other than arm64 > code > and qspinlocks, neither of which are used on powerpc. So adding them should be > pretty harmless. > > cheers > signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > Hi all, > > This is v6 of the series. > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > Link for v2: https://lkml.org/lkml/2015/9/16/527 > Link for v3: https://lkml.org/lkml/2015/10/12/368 > Link for v4: https://lkml.org/lkml/2015/10/14/670 > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > Changes since v5: > > * rebase on the next branch of powerpc. > > * pull two fix and one testcase patches out, which are already > sent separately > > * some clean up or code format fixing. > > > Paul, Peter and Will, thank you for your comments and suggestions in the > review > of previous versions. From this version on, This series is against the next > branch of powerpc tree, because most of the code touch arch/powerpc/*. Sorry if we already discussed this, but did we decide how we were going to merge this? There's the one patch to generic code and then three powerpc patches. It'd make most sense for it to go via powerpc I think. Given that the change to generic code is relatively trivial I'll plan to merge this unless someone objects. Also it is pretty late in the -next cycle for something like this. But AFAICS there are no users of these "atomic*relaxed" variants yet other than arm64 code and qspinlocks, neither of which are used on powerpc. So adding them should be pretty harmless. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > Hi all, > > This is v6 of the series. > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > Link for v2: https://lkml.org/lkml/2015/9/16/527 > Link for v3: https://lkml.org/lkml/2015/10/12/368 > Link for v4: https://lkml.org/lkml/2015/10/14/670 > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > Changes since v5: > > * rebase on the next branch of powerpc. > > * pull two fix and one testcase patches out, which are already > sent separately > > * some clean up or code format fixing. > > > Paul, Peter and Will, thank you for your comments and suggestions in the > review > of previous versions. From this version on, This series is against the next > branch of powerpc tree, because most of the code touch arch/powerpc/*. Sorry if we already discussed this, but did we decide how we were going to merge this? There's the one patch to generic code and then three powerpc patches. It'd make most sense for it to go via powerpc I think. Given that the change to generic code is relatively trivial I'll plan to merge this unless someone objects. Also it is pretty late in the -next cycle for something like this. But AFAICS there are no users of these "atomic*relaxed" variants yet other than arm64 code and qspinlocks, neither of which are used on powerpc. So adding them should be pretty harmless. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > This is v6 of the series. > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > Changes since v5: > > > > * rebase on the next branch of powerpc. > > > > * pull two fix and one testcase patches out, which are already > > sent separately > > > > * some clean up or code format fixing. > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in the > > review > > of previous versions. From this version on, This series is against the next > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > Sorry if we already discussed this, but did we decide how we were going to > merge this? There's the one patch to generic code and then three powerpc > patches. > We might have "discussed" this ;-) As I proposed this would go to the powerpc next in this mail: http://marc.info/?l=linux-kernel=144660021417639=2 Regards, Boqun > It'd make most sense for it to go via powerpc I think. Given that the change > to > generic code is relatively trivial I'll plan to merge this unless someone > objects. > > Also it is pretty late in the -next cycle for something like this. But AFAICS > there are no users of these "atomic*relaxed" variants yet other than arm64 > code > and qspinlocks, neither of which are used on powerpc. So adding them should be > pretty harmless. > > cheers > signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Fri, Dec 18, 2015 at 09:12:50AM -0800, Davidlohr Bueso wrote: > I've left this series testing overnight on a power7 box and so far so good, > nothing has broken. Davidlohr, thank you for your testing! Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Fri, Dec 18, 2015 at 09:12:50AM -0800, Davidlohr Bueso wrote: > I've left this series testing overnight on a power7 box and so far so good, > nothing has broken. Davidlohr, thank you for your testing! Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
I've left this series testing overnight on a power7 box and so far so good, nothing has broken. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
I've left this series testing overnight on a power7 box and so far so good, nothing has broken. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
Hi all,
This is v6 of the series.
Link for v1: https://lkml.org/lkml/2015/8/27/798
Link for v2: https://lkml.org/lkml/2015/9/16/527
Link for v3: https://lkml.org/lkml/2015/10/12/368
Link for v4: https://lkml.org/lkml/2015/10/14/670
Link for v5: https://lkml.org/lkml/2015/10/26/141
Changes since v5:
* rebase on the next branch of powerpc.
* pull two fix and one testcase patches out, which are already
sent separately
* some clean up or code format fixing.
Paul, Peter and Will, thank you for your comments and suggestions in the review
of previous versions. From this version on, This series is against the next
branch of powerpc tree, because most of the code touch arch/powerpc/*.
Relaxed/acquire/release variants of atomic operations {add,sub}_return and
{cmp,}xchg are introduced by commit:
"atomics: add acquire/release/relaxed variants of some atomic operations"
and {inc,dec}_return has been introduced by commit:
"locking/asm-generic: Add _{relaxed|acquire|release}() variants for inc/dec
atomics"
By default, the generic code will implement a relaxed variant as a full ordered
atomic operation and release/acquire a variant as a relaxed variant with a
necessary general barrier before or after.
On PPC, which has a weak memory order model, a relaxed variant can be
implemented more lightweightly than a full ordered one. Further more, release
and acquire variants can be implemented with arch-specific lightweight
barriers.
Therefore this patchset implements the relaxed/acquire/release variants based
on PPC memory model and specific barriers.
The patchset consists of 4 parts:
1. Allow architectures to define their own __atomic_op_*() helpers
to build other variants based on relaxed.
2. Implement atomic{,64}_{add,sub,inc,dec}_return_* variants
3. Implement xchg_* and atomic{,64}_xchg_* variants
4. Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
This patchset is against:
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
commit 5f337e3e5b04b32793fd51adab438d46df99c933
and has been tested by 0day. I also have run build and boot tests of this in
both guest(pseries) and host(powernv) environments.
Looking forward to any suggestion, question and comment ;-)
Regards,
Boqun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
Hi all,
This is v6 of the series.
Link for v1: https://lkml.org/lkml/2015/8/27/798
Link for v2: https://lkml.org/lkml/2015/9/16/527
Link for v3: https://lkml.org/lkml/2015/10/12/368
Link for v4: https://lkml.org/lkml/2015/10/14/670
Link for v5: https://lkml.org/lkml/2015/10/26/141
Changes since v5:
* rebase on the next branch of powerpc.
* pull two fix and one testcase patches out, which are already
sent separately
* some clean up or code format fixing.
Paul, Peter and Will, thank you for your comments and suggestions in the review
of previous versions. From this version on, This series is against the next
branch of powerpc tree, because most of the code touch arch/powerpc/*.
Relaxed/acquire/release variants of atomic operations {add,sub}_return and
{cmp,}xchg are introduced by commit:
"atomics: add acquire/release/relaxed variants of some atomic operations"
and {inc,dec}_return has been introduced by commit:
"locking/asm-generic: Add _{relaxed|acquire|release}() variants for inc/dec
atomics"
By default, the generic code will implement a relaxed variant as a full ordered
atomic operation and release/acquire a variant as a relaxed variant with a
necessary general barrier before or after.
On PPC, which has a weak memory order model, a relaxed variant can be
implemented more lightweightly than a full ordered one. Further more, release
and acquire variants can be implemented with arch-specific lightweight
barriers.
Therefore this patchset implements the relaxed/acquire/release variants based
on PPC memory model and specific barriers.
The patchset consists of 4 parts:
1. Allow architectures to define their own __atomic_op_*() helpers
to build other variants based on relaxed.
2. Implement atomic{,64}_{add,sub,inc,dec}_return_* variants
3. Implement xchg_* and atomic{,64}_xchg_* variants
4. Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
This patchset is against:
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
commit 5f337e3e5b04b32793fd51adab438d46df99c933
and has been tested by 0day. I also have run build and boot tests of this in
both guest(pseries) and host(powernv) environments.
Looking forward to any suggestion, question and comment ;-)
Regards,
Boqun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
