Hi Al,
Ping and sorry to bother you.
Could you please have a look at my question? Thank you!
Regards,
Boqun Feng
On Wed, Mar 18, 2015 at 01:27:24PM +0800, Boqun Feng wrote:
On Fri, Mar 13, 2015 at 09:45:59AM -0400, Paul Moore wrote:
On Monday, March 09, 2015 04:24:32 PM Boqun Feng wrote
Ping.
Any opinion?
Thanks,
Boqun Feng
On Wed, Feb 25, 2015 at 8:31 PM, Boqun Feng boqun.f...@gmail.com wrote:
In the current implementation of getname_flags, filename in the
user-space will be recopied if it takes more space that
EMBEDDED_NAME_MAX, however, at this moment, EMBEDDED_NAME_MAX
`, is not needed
anymore.
Signed-off-by: Boqun Feng boqun.f...@gmail.com
---
v1 -- v2:
Rebase the patch onto the for-next branch of Al's vfs repo.
fs/namei.c | 45 -
include/linux/fs.h | 1 -
2 files changed, 28 insertions(+), 18 deletions(-)
diff
Hi Richard,
On Sun, Mar 29, 2015 at 12:13:29PM +0200, Richard Weinberger wrote:
On Wed, Mar 25, 2015 at 7:45 PM, Boqun Feng boqun.f...@gmail.com wrote:
In the current implementation of getname_flags, a file name in the
user-space will be recopied if it takes more space
On Sun, Mar 29, 2015 at 12:14:24PM +0200, Richard Weinberger wrote:
On Sun, Mar 29, 2015 at 6:27 AM, Boqun Feng boqun.f...@gmail.com wrote:
Ping.
This patch has been tested by 0day test bot.
I hope you did more than build test this patch...
I did, I boot the new kernel and ran some
Ping.
This patch has been tested by 0day test bot.
Thanks,
Boqun Feng
On Thu, Mar 26, 2015 at 02:45:52AM +0800, Boqun Feng wrote:
In the current implementation of getname_flags, a file name in the
user-space will be recopied if it takes more space that
EMBEDDED_NAME_MAX, however
...@zeniv.linux.org.uk
Cc: Paul Moore pmo...@redhat.com
Signed-off-by: Boqun Feng boqun.f...@gmail.com
---
fs/namei.c | 50 +++---
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index c83145a..3be372b 100644
--- a/fs/namei.c
On Fri, Mar 13, 2015 at 09:45:59AM -0400, Paul Moore wrote:
On Monday, March 09, 2015 04:24:32 PM Boqun Feng wrote:
Ping.
Any opinion?
You might want to look at some of the recent changes to Al's vfs.git#for-next
branch; at the very least it looks like your patch should be rebased
Hi,
On Mon, Apr 20, 2015 at 05:55:07PM +0200, Jan Kara wrote:
On Fri 17-04-15 20:35:30, Boqun Feng wrote:
Hi Al,
I'm trying to clean that part of code you mentioned, and I found I have
to export the symbols 'getname' and 'putname' as follow to replace that
__getname() caller
...@zeniv.linux.org.uk
Signed-off-by: Boqun Feng boqun.f...@gmail.com
---
drivers/staging/lustre/lustre/llite/dir.c | 60 ++
.../staging/lustre/lustre/llite/llite_internal.h | 2 +-
drivers/staging/lustre/lustre/llite/namei.c| 2 +-
3 files changed, 18
tests are welcome. Thank you.
;-)
Regards,
Boqun Feng
Boqun Feng (2):
vfs: Export symbol 'getname' and 'putname'
staging: lustre: replace ll_{get,put}name() with {get,put}name()
drivers/staging/lustre/lustre/llite/dir.c | 60 ++
.../staging/lustre/lustre/llite
-off-by: Boqun Feng boqun.f...@gmail.com
---
fs/namei.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/fs/namei.c b/fs/namei.c
index c83145a..472911c 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -199,11 +199,23 @@ error:
return err;
}
+/**
+ * getname() - Get a file
and these idiotic ioctls were something
we had to live with.
But lustre is in staging code, and we shouldn't export symbols just for
shitty staging code.
Intead lustre should clean up their mess and get rid of these ioctls
that do path name lookups.
OK, good point. Thank you!
Regards,
Boqun Feng
Hi Al,
On Sun, Apr 12, 2015 at 02:13:18AM +0100, Al Viro wrote:
BTW, looking at the __getname() callers... Lustre one sure as hell looks
bogus:
char *tmp = __getname();
if (!tmp)
return ERR_PTR(-ENOMEM);
len = strncpy_from_user(tmp, filename,
Hi Al,
On Sun, Apr 12, 2015 at 12:56:55AM +0100, Al Viro wrote:
On Tue, Apr 07, 2015 at 04:38:26PM +0800, Boqun Feng wrote:
Ping again...
What exactly does it buy us? You need a pathname just a bit under 4Kb, which,
with all due respect, is an extremely rare case. Resulting code is more
filename, iname[1]), GFP_KERNEL);
and we are done - result-iname+1 will be within the allocated object,
no matter what.
Thank you for your response. As long as the actual size of result is not
a power of 2, the problem will not happen.(Maybe add a comment before
struct filename)
Regards,
Boqun
On Fri, Apr 17, 2015 at 08:35:30PM +0800, Boqun Feng wrote:
Hi Al,
On Sun, Apr 12, 2015 at 02:13:18AM +0100, Al Viro wrote:
BTW, looking at the __getname() callers... Lustre one sure as hell looks
bogus:
char *tmp = __getname();
if (!tmp)
return
Ping again...
Thanks,
Boqun Feng
On Sun, Mar 29, 2015 at 12:27:44PM +0800, Boqun Feng wrote:
Ping.
This patch has been tested by 0day test bot.
Thanks,
Boqun Feng
On Thu, Mar 26, 2015 at 02:45:52AM +0800, Boqun Feng wrote:
In the current implementation of getname_flags, a file
Hi Yuyang,
On Tue, Jun 16, 2015 at 03:26:05AM +0800, Yuyang Du wrote:
@@ -5977,36 +5786,6 @@ static void attach_tasks(struct lb_env *env)
}
#ifdef CONFIG_FAIR_GROUP_SCHED
-/*
- * update tg-load_weight by folding this cpu's load_avg
- */
-static void
Hi Yuyang,
On Fri, Jun 19, 2015 at 11:11:16AM +0800, Yuyang Du wrote:
On Fri, Jun 19, 2015 at 03:57:24PM +0800, Boqun Feng wrote:
This rewrite patch does not NEED to aggregate entity's load to cfs_rq,
but rather directly update the cfs_rq's load (both runnable and blocked),
so
Hi Yuyang,
On Fri, Jun 19, 2015 at 07:05:54AM +0800, Yuyang Du wrote:
On Fri, Jun 19, 2015 at 02:00:38PM +0800, Boqun Feng wrote:
However, update_cfs_rq_load_avg() only updates cfs_rq-avg, the change
won't be contributed or aggregated to cfs_rq's parent in the
for_each_leaf_cfs_rq loop
Hi Yuyang,
We have tested your V7 patchset as follow:
On Intel(R) Xeon(R) CPU X5690 (12 cores), run 12 stress and 6 dbench.
Results show that usages of some CPUs are less than 50% sometimes.
We would like to test your V8 patchset, but I can neither find it in a
lkml archive, nor in my lkml
On Wed, Jun 17, 2015 at 11:06:50AM +0800, Boqun Feng wrote:
Hi Yuyang,
I've run the test as follow on tip/master without and with your
patchset:
On a 12-core system (Intel(R) Xeon(R) CPU X5690 @ 3.47GHz)
run stress --cpu 12
run dbench 1
Sorry, I forget to say that `stress --cpu 12
Hi Yuyang,
On Wed, Jun 17, 2015 at 11:11:01AM +0800, Yuyang Du wrote:
Hi,
The sched_debug is informative, lets first give it some analysis.
The workload is 12 CPU hogging tasks (always runnable) and 1 dbench
task doing fs ops (70% runnable) running at the same time.
Actually, these 13
-by: Boqun Feng boqun.f...@gmail.com
---
kernel/sched/fair.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4b6e5f6..341a51f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -616,15 +616,10 @@ static inline u64
Ping. Any idea on this one?
On Thu, Jul 02, 2015 at 10:25:52PM +0800, Boqun Feng wrote:
Since commit: 4bf0b77158 (sched: remove do_div() from
__sched_slice()), the logic of __sched_period() can be implemented as a
single if-else without any local variable, so this patch cleans it up
Hi Peter,
On Mon, Jul 06, 2015 at 02:49:59PM +0200, Peter Zijlstra wrote:
On Mon, Jul 06, 2015 at 08:41:26PM +0800, Boqun Feng wrote:
Ping. Any idea on this one?
I think I queued this one.
Sorry, I only had looked up in the tip tree.. just found it on your
tree. Thank you!
Regards,
Boqun
Hi Ingo,
On Mon, Jul 06, 2015 at 02:53:50PM +0200, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Mon, Jul 06, 2015 at 08:41:26PM +0800, Boqun Feng wrote:
Ping. Any idea on this one?
I think I queued this one.
Yeah, and I applied it from you earlier today
We have call_rcu_func_t for a quite while, but we still use explicit
function pointer type equivalents in some places, this patch replace
these equivalent types with call_rcu_func_t to gain better readability.
Signed-off-by: Boqun Feng boqun.f...@gmail.com
---
kernel/rcu/rcutorture.c | 2
, this can also help cscope to generate a better database for
code reading.
Signed-off-by: Boqun Feng boqun.f...@gmail.com
---
include/linux/rcupdate.h | 10 +-
include/linux/rcutiny.h | 2 +-
include/linux/rcutree.h | 2 +-
kernel/rcu/rcutorture.c | 4 ++--
kernel/rcu/srcu.c| 2
Commit (rcu: Create a synchronize_rcu_mult()) in linux-rcu.git#rcu/next
branch has introduced rcu_callback_t as the type for rcu callback
functions and call_rcu_func_t has been introduced for a while. This patch
series uses the rcu_callback_t and call_rcu_func_t to save a few lines of
code.
This
Hi Peter,
On Mon, Aug 10, 2015 at 04:24:17PM +0200, Peter Zijlstra wrote:
On Mon, Aug 10, 2015 at 09:49:24PM +0800, Boqun Feng wrote:
snip
Though I don't want to have a locking order like that either, we can't
stop others from using that order(maybe a good design review will) and
lockdep
Hi Peter and Ingo,
I'm now learning the code of lockdep and find that nested lock may not
be handled correctly because we fail to take held_lock merging into
consideration. I come up with an example and hope that could explain my
concern.
Please consider this lock/unlock sequence, I also put a
Hi Peter,
On Mon, Aug 10, 2015 at 01:42:28PM +0200, Peter Zijlstra wrote:
On Mon, Aug 10, 2015 at 05:52:47PM +0800, Boqun Feng wrote:
Hi Peter and Ingo,
I'm now learning the code of lockdep and find that nested lock may not
be handled correctly because we fail to take held_lock merging
Hi Yuyang,
On Mon, Jul 27, 2015 at 03:56:34AM +0800, Yuyang Du wrote:
On Mon, Jul 27, 2015 at 11:21:15AM +0800, Boqun Feng wrote:
Hi Yuyang,
On Mon, Jul 27, 2015 at 02:43:25AM +0800, Yuyang Du wrote:
Hi Boqun,
On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote
Hi Yuyang,
On Mon, Jul 27, 2015 at 02:43:25AM +0800, Yuyang Du wrote:
Hi Boqun,
On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote:
The point is that you have already tracked the sum of runnable_load_avg
and blocked_load_avg in cfs_rq-avg.load_avg. If you're going to track
part
On Mon, Jul 27, 2015 at 11:21:15AM +0800, Boqun Feng wrote:
Hi Yuyang,
On Mon, Jul 27, 2015 at 02:43:25AM +0800, Yuyang Du wrote:
Hi Boqun,
On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote:
The point is that you have already tracked the sum of runnable_load_avg
Hi Yuyang,
On Mon, Jul 27, 2015 at 04:34:09AM +0800, Yuyang Du wrote:
On Mon, Jul 27, 2015 at 12:04:20PM +0800, Boqun Feng wrote:
~~~
1) blocked load is more difficult to track, hint, migrate
On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote:
The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg.
Before this series, sometimes the runnable_load_avg is used, and sometimes
the load_avg is used. Completely replacing all uses of runnable_load_avg
with
Hi Yuyang,
On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote:
The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg.
Before this series, sometimes the runnable_load_avg is used, and sometimes
the load_avg is used. Completely replacing all uses of runnable_load_avg
On Tue, Jul 21, 2015 at 08:44:01AM +0800, Yuyang Du wrote:
On Tue, Jul 21, 2015 at 09:08:07AM +0800, Boqun Feng wrote:
Hi Yuyang,
On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote:
The cfs_rq's load_avg is composed of runnable_load_avg and
blocked_load_avg.
Before
On Tue, Jul 21, 2015 at 06:18:46PM +0800, Boqun Feng wrote:
On Tue, Jul 21, 2015 at 08:44:01AM +0800, Yuyang Du wrote:
On Tue, Jul 21, 2015 at 09:08:07AM +0800, Boqun Feng wrote:
Hi Yuyang,
On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote:
The cfs_rq's load_avg
On Sat, Oct 24, 2015 at 07:53:56PM +0800, Boqun Feng wrote:
> On Sat, Oct 24, 2015 at 12:26:27PM +0200, Peter Zijlstra wrote:
> >
> > Right, futexes are a pain; and I think we all agreed we didn't want to
> > go rely on implementation details unless we absolutely _have_
On Wed, Oct 21, 2015 at 09:48:25PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 21, 2015 at 12:35:23PM -0700, Paul E. McKenney wrote:
> > > > > > I ask this because I recall Peter once bought up a discussion:
> > > > > >
> > > > > > https://lkml.org/lkml/2015/8/26/596
>
> > > So a full barrier on
On Wed, Oct 21, 2015 at 12:36:38PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> > > I am not seeing a sync there, but I really have to defer to the
> > > maintainers on this
Implement xchg_relaxed and atomic{,64}_xchg_relaxed, based on these
_relaxed variants, release/acquire variants and fully ordered versions
can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
-by: Boqun Feng <boqun.f...@gmail.com>
---
include/linux/atomic.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 27e580d..947c1dc 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -43,20 +43,29 @@ static
RIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics").
Cc: <sta...@vger.kernel.org> # 3.4+
Sig
RIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics").
Cc: <sta...@vger.kernel.org> # 3.4+
Sig
barriers.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
arch/powerpc/include/asm/atomic.h | 10 +++
arch/powerpc/include/asm/cmpxchg.h | 149 -
2 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/atomic.h
that we can examine their assembly code.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
lib/atomic64_test.c | 120 ++--
1 file changed, 79 insertions(+), 41 deletions(-)
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index 83
Hi all,
This is v5 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
Changes since v4:
* define PPC_ATOMIC_ENTRY_BARRIER as
on the platform without "lwsync", we can use "isync"
rather than "sync" as an acquire barrier. Therefore in
__atomic_op_acquire() we use PPC_ACQUIRE_BARRIER, which is barrier() on
UP, "lwsync" if available and "isync" otherwise.
Implement atomic{
On Mon, Oct 26, 2015 at 05:50:52PM +0800, Boqun Feng wrote:
> This patch fixes two problems to make value-returning atomics and
> {cmp}xchg fully ordered on PPC.
>
> According to memory-barriers.txt:
>
> > Any atomic operation that modifies some state in memory and returns
On Mon, Oct 26, 2015 at 11:20:01AM +0900, Michael Ellerman wrote:
>
> Sorry guys, these threads are so long I tend not to read them very actively :}
>
> Looking at the system call path, the straight line path does not include any
> barriers. I can't see any hidden in macros either.
>
> We also
On Mon, Oct 26, 2015 at 02:20:21PM +1100, Paul Mackerras wrote:
> On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> > > I am not seeing a sync there, but I really have to defer to the
> > > maintainers on this
On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > This patch fixes two problems to make value-returning atomics and
> > {cmp}xchg fully ordered on PPC.
>
> Hi Boqun,
>
> Can you please split
On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
> On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > > This patch fixes two problems to make value-returning atomics and
> > > {cm
On Sat, Oct 24, 2015 at 12:26:27PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 22, 2015 at 08:07:16PM +0800, Boqun Feng wrote:
> > On Wed, Oct 21, 2015 at 09:48:25PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 21, 2015 at 12:35:23PM -0700, Paul E. McKenney wrote:
>
On Mon, Oct 26, 2015 at 02:26:01PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 26, 2015 at 01:59:44PM +0100, Daniel Wagner wrote:
> > Hi Boqun,
> >
> > On 10/26/2015 01:04 PM, Boqun Feng wrote:
> > > On Tue, Oct 20, 2015 at 09:28:0
Hi Daniel,
On Tue, Oct 20, 2015 at 09:28:07AM +0200, Daniel Wagner wrote:
> +
> +/*
> + * The thing about the wake_up_state() return value; I think we can ignore
> it.
> + *
> + * If for some reason it would return 0, that means the previously waiting
> + * task is already running, so it will
Hi Oleg,
On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
[snip]
>
> Unfortunately this doesn't look exactly right...
>
> spin_unlock_wait() is not equal to "while (locked) relax", the latter
> is live-lockable or at least sub-optimal: we do not really need to spin
Just be
On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> Hi Oleg,
>
> On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
> [snip]
> >
> > Unfortunately this doesn't look exactly right...
> >
> > spin_unlock_wait() is not equal to "whil
On Wed, Nov 11, 2015 at 08:39:53PM +0100, Oleg Nesterov wrote:
> On 11/11, Peter Zijlstra wrote:
> >
> > On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> >
> > > Just be curious, should spin_unlock_wait() semantically be an ACQUIRE?
> >
>
On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
[snip]
>
> I cannot resist suggesting that any lock that interacts with
> spin_unlock_wait() must have all relevant acquisitions followed by
> smp_mb__after_unlock_lock().
>
But
1. This would expand the purpose of
On Thu, Nov 12, 2015 at 04:00:58PM +0100, Oleg Nesterov wrote:
> On 11/12, Boqun Feng wrote:
[snip]
> >
> > Hmm.. probably incorrect.. because the ACQUIRE semantics of spin_lock()
> > only guarantees that the memory operations following spin_lock() can't
> > be reo
On Fri, Oct 30, 2015 at 08:56:33AM +0800, Boqun Feng wrote:
> On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
> > On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> > > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > > > This pa
s fully
ordered" for PPC_ATOMIC_ENTRY_BARRIER definition.
Cc: <sta...@vger.kernel.org> # 3.4+
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
arch/powerpc/include/asm/cmpxchg.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/inclu
0/14/970
To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
the fully-ordered semantics.
This also makes futex atomics fully ordered, which can avoid possible
memory ordering problems if userspace code relies on futex system call
for fully ordered semantics.
Cc: <sta...@vger
On Mon, Nov 02, 2015 at 09:22:40AM +0800, Boqun Feng wrote:
> > On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
> > > To summerize:
> > >
> > > patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
> > > powerpc patches
that we can examine their assembly code.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
This is separated from the patchset of powerpc atomic variants implementation,
whose link is:
https://lkml.org/lkml/2015/10/26/141
Based on locking/core branch of the tip tree, tested by 0day.
barriers.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
arch/powerpc/include/asm/atomic.h | 10 +++
arch/powerpc/include/asm/cmpxchg.h | 149 -
2 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/atomic.h
Implement xchg_relaxed and atomic{,64}_xchg_relaxed, based on these
_relaxed variants, release/acquire variants and fully ordered versions
can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
defined as smp_lwsync() + _relaxed +
smp_mb__after_atomic() to guarantee a full barrier.
Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other
variants with these helpers.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
arch/powerpc/include/asm/atomic.h | 116
Hi all,
This is v4 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
Changes since v3:
* avoid to introduce smp_acquire_barrier__after_atomic()
(Will Deacon)
*
that we can examine their assembly code.
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
lib/atomic64_test.c | 120 ++--
1 file changed, 79 insertions(+), 41 deletions(-)
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index 83
-by: Boqun Feng <boqun.f...@gmail.com>
---
include/linux/atomic.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 27e580d..947c1dc 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -43,20 +43,29 @@ static
.au>
Cc: <sta...@vger.kernel.org> # 3.4+
Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
---
arch/powerpc/include/asm/cmpxchg.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/cmpxchg.h
b/arch/powerpc/include/asm/cmpxchg.h
i
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
[snip]
> >
> > So lots of little confusions added up to complete fail :-{
> >
> > Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
> > forgot: but
On Thu, Oct 15, 2015 at 09:30:40AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 15, 2015 at 12:48:03PM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote:
[snip]
> >
> > > Why not try creating a longer litmus test
On Wed, Oct 14, 2015 at 10:06:13AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 14, 2015 at 08:51:34AM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 11:10:00AM +1100, Michael Ellerman wrote:
>
> > > Thanks for fixing this. In future you should send a patch like this as a
On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 14, 2015 at 11:55:56PM +0800, Boqun Feng wrote:
> > According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
> > versions all need to imply a full barrier, however they are now just
>
On Thu, Oct 15, 2015 at 11:35:44AM +0100, Will Deacon wrote:
>
> So arm64 is ok. Doesn't lwsync order store->store observability for PPC?
>
I did some litmus and put the result here. My understanding might be
wrong, and I think Paul can explain the lwsync and store->store order
better ;-)
On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
>
> Am I missing something here? If not, it seems to me that you need
> the leading lwsync to instead be a sync.
>
> Of course, if I am not missing something, then this applies also to the
> value-returning RMW atomic operations
On Mon, Oct 19, 2015 at 12:23:24PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> > This is confusing me right now. ;-)
> >
> > Let's use a simple example for only one primitive, as I understand it,
> > if we say a primiti
On Mon, Oct 19, 2015 at 08:46:02PM -0700, Davidlohr Bueso wrote:
> On Tue, 20 Oct 2015, Boqun Feng wrote:
>
> >>@@ -93,7 +94,7 @@ static __always_inline void queued_spin_unlock(struct
> >>qspinlock *lock)
> >>/*
> >> * smp_mb__before_atomic
Hi Waiman,
On Thu, Oct 15, 2015 at 06:51:03PM -0400, Waiman Long wrote:
> This patch replaces the cmpxchg() and xchg() calls in the native
> qspinlock code with the more relaxed _acquire or _release versions of
> those calls to enable other architectures to adopt queued spinlocks
> with less
On Mon, Oct 12, 2015 at 04:30:48PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 09, 2015 at 07:33:28PM +0100, Will Deacon wrote:
> > On Fri, Oct 09, 2015 at 10:43:27AM -0700, Paul E. McKenney wrote:
> > > On Fri, Oct 09, 2015 at 10:51:29AM +0100, Will Deacon wrote:
[snip]
>
> > > > We could also
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
>
On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > Suppose we have something like the following, where "a" and "x" are both
> > > initially
Hi Paul,
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
[snip]
> > To that end, the herd tool can make a diagram of what it thought
> > happened, and I have attached it. I used this diagram t
On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
[snip]
> >
> > I'm afraid more than that, the above litmus also shows that
> >
> > CPU 0
On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 20, 2015 at 11:21:47AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 03:15:32PM +0800, Boqun Feng wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > &
On Sat, Oct 10, 2015 at 09:58:05AM +0800, Boqun Feng wrote:
> Hi Peter,
>
> Sorry for replying late.
>
> On Thu, Oct 01, 2015 at 02:27:16PM +0200, Peter Zijlstra wrote:
> > On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> > > Unlike other atomic o
On Tue, Oct 06, 2015 at 06:06:50PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 24, 2015 at 09:21:22PM +0800, Boqun Feng wrote:
> > > Included in it are some of the details on this subject, because a wakeup
> > > has two prior states that are of importance, the
Hi Paul,
On Thu, Oct 01, 2015 at 11:03:01AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 01, 2015 at 07:13:04PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 01, 2015 at 08:09:09AM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 01, 2015 at 02:24:40PM +0200, Peter Zijlstra wrote:
> >
> > > > I
On Mon, Oct 12, 2015 at 08:46:21AM +0200, Peter Zijlstra wrote:
> On Sun, Oct 11, 2015 at 06:25:20PM +0800, Boqun Feng wrote:
> > On Sat, Oct 10, 2015 at 09:58:05AM +0800, Boqun Feng wrote:
> > > Hi Peter,
> > >
> > > Sorry for replying late.
> > >
&
On Mon, Oct 12, 2015 at 10:30:34AM +0100, Will Deacon wrote:
> On Wed, Sep 16, 2015 at 04:49:29PM +0100, Boqun Feng wrote:
> > Some atomic operations now have _{relaxed, acquire, release} variants,
> > this patch then adds some trivial tests for two purpose:
> >
>
On Sun, Oct 11, 2015 at 05:40:44PM -0700, Paul E. McKenney wrote:
> On Sun, Oct 11, 2015 at 11:26:40PM +0800, Boqun Feng wrote:
> > On Tue, Oct 06, 2015 at 06:06:50PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 24, 2015 at 09:21:22PM +0800, Boqun Feng wrote:
> > >
ellerman.id.au>", "Thomas
> Gleixner <tglx@linutronix.d
> e>", "Will Deacon <will.dea...@arm.com>", "\"Paul E. McKenney\"
> <paul...@linux.vnet.ibm.com>", "Waiman Long <waiman.l...@hp.com>", "Davidlohr
1 - 100 of 1674 matches
Mail list logo
