[merged] seqlock-dont-smp_rmb-in-seqlock-reader-spin-loop.patch removed from -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled
     seqlock: don't smp_rmb in seqlock reader spin loop
has been removed from the -mm tree.  Its filename was
     seqlock-dont-smp_rmb-in-seqlock-reader-spin-loop.patch

This patch was dropped because it was merged into mainline or a subsystem tree

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: seqlock: don't smp_rmb in seqlock reader spin loop
From: Milton Miller <miltonm@xxxxxxx>

Move the smp_rmb after cpu_relax loop in read_seqlock and add ACCESS_ONCE
to make sure the test and return are consistent.

A multi-threaded core in the lab didn't like the update from 2.6.35 to
2.6.36, to the point it would hang during boot when multiple threads were
active.  Bisection showed af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867
("clockevents: Remove the per cpu tick skew") as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.

Experimentation showed the combination of cpu_relax and smp_rmb was
significantly slowing the progress of other threads sharing the core, and
this patch is effective in avoiding the hang.

A theory is the rmb is affecting the whole core while the cpu_relax is
causing a resource rebalance flush, together they cause an interfernce
cadance that is unbroken when the seqlock reader has interrupts disabled.

At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 ("kernel: optimise seqlock")
didn't affect this patch application, but after some study that affected
seqcount not seqlock.  The new seqcount was not factored back into the
seqlock.  I defer that the future.

While the removal of the timer interrupt offset created contention for the
xtime lock while a cpu does the additonal work to update the system clock,
the seqlock implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.

Signed-off-by: Milton Miller <miltonm@xxxxxxx>
Cc: Nick Piggin <npiggin@xxxxxxxxx>
Cc: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
Cc: Anton Blanchard <anton@xxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Acked-by: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
Cc: Andi Kleen <andi@xxxxxxxxxxxxxx>
Cc: David Howells <dhowells@xxxxxxxxxx>
Cc: "Paul E. McKenney" <paulmck@xxxxxxxxxx>
Cc: <stable@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

 include/linux/seqlock.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN include/linux/seqlock.h~seqlock-dont-smp_rmb-in-seqlock-reader-spin-loop include/linux/seqlock.h
--- a/include/linux/seqlock.h~seqlock-dont-smp_rmb-in-seqlock-reader-spin-loop
+++ a/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
 	unsigned ret;
 
 repeat:
-	ret = sl->sequence;
-	smp_rmb();
+	ret = ACCESS_ONCE(sl->sequence);
 	if (unlikely(ret & 1)) {
 		cpu_relax();
 		goto repeat;
 	}
+	smp_rmb();
 
 	return ret;
 }
_

Patches currently in -mm which might be from miltonm@xxxxxxx are

linux-next.patch

--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Newbies FAQ]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux