12 May, 2011

1 commit

  • 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.

    Cc:
    Signed-off-by: Milton Miller
    Cc:
    Cc: Linus Torvalds
    Cc: Andi Kleen
    Cc: Nick Piggin
    Cc: Benjamin Herrenschmidt
    Cc: Anton Blanchard
    Cc: Paul McKenney
    Acked-by: Eric Dumazet
    Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
    Signed-off-by: Thomas Gleixner

    Milton Miller
     

07 Jan, 2011

1 commit

  • Add branch annotations for seqlock read fastpath, and introduce
    __read_seqcount_begin and __read_seqcount_end functions, that can avoid the
    smp_rmb() if used carefully. These will be used by store-free path walking
    algorithm performance is critical and seqlocks are in use.

    Signed-off-by: Nick Piggin

    Nick Piggin
     

25 Apr, 2008

1 commit

  • Thomas Gleixner debugged a particularly ugly seqlock related livelock:
    do not process the seq-read section if we know it beforehand that the
    test at the end of the section will fail ...

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

28 Apr, 2007

1 commit


18 Feb, 2007

1 commit


13 Dec, 2006

1 commit

  • seqlock_init() needs to use spin_lock_init() for dynamic locks, so that
    lockdep is notified about the presence of a new lock.

    (this is a fallout of the recent networking merge, which started using
    the so-far unused seqlock_init() API.)

    This fix solves the following lockdep-internal warning on current -git:

    INFO: trying to register non-static key.
    the code is fine but needs lockdep annotation.
    turning off the locking correctness validator.
    __lock_acquire+0x10c/0x9f9
    lock_acquire+0x56/0x72
    _spin_lock+0x35/0x42
    neigh_destroy+0x9d/0x12e
    neigh_periodic_timer+0x10a/0x15c
    run_timer_softirq+0x126/0x18e
    __do_softirq+0x6b/0xe6
    do_softirq+0x64/0xd2
    ksoftirqd+0x82/0x138

    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

04 Jul, 2006

1 commit


26 Apr, 2006

1 commit


11 Apr, 2006

1 commit

  • In vsyscall function do_vgettimeofday(), some functions are declared as
    inlined, which is a hint for gcc to compile the function inlined but it
    not forced. Sometimes compiler does not compile the function as
    inlined, so here inline is replaced by __always_inline prefix.

    It does not happen in gcc compiler actually, but it possibly happens.

    Signed-off-by: bibo mao
    Signed-off-by: Linus Torvalds

    mao, bibo
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds