[lkml]   [2000]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: GCC proposal for "@" asm constraint
    On Fri, Sep 22, 2000 at 10:35:16AM -0700, Linus Torvalds wrote:
    > On Fri, 22 Sep 2000, Andrea Arcangeli wrote:
    > >
    > > This patch fixes the spinlock problems in read_lock/write_lock and also some
    > > alpha SMP race where clear_bit isn't enforcing a memory barrier
    > Why would clear_bit() be a memory barrier?

    It isn't infact (with "alpha SMP race" I meant the common code places that are
    assuming clear_bit is a memory barrier while it correctly isn't on the alpha).

    > Anything that expects clear_bit() to be a memory barrier should be fixed.

    That's what the patch does.

    > Anything that wants a spinlock should use the spinlocks. Not the bit ops.
    > They are atomic, but they are not memory barriers.


    For things like TryLockPage we want to not use the spinlock to be allowed to
    spin not in the bit 0 but in the PG_locked bit (being lock_page a schedule
    aware lock that's not problematic for the preemptive UP kernel either) and so
    there we still need a kind of smp_mb__before/after_clear_bit to avoid suprious
    lock on the bus on IA32 (and IA32 also needs a compiler barrier() too without
    the foolgcc stuff). Softnet isn't an issue for preemptive UP kernel either
    because it always only trylock and it wants to save fields too by using
    different bits in the ->state field.

    If you don't like the name smp_mb__before/after_clear_bit (not that I like it
    too much too) suggestions are welcome. Maybe we could use a single
    smp_mb__across_bitops() instead? I didn't do that because it would be less
    finegrined and not completly correct because bitops includes also
    test_and_set/clear/change_bit that doesn't need an explicit barrier and they
    does a mb when the lock is taken and they just clobbers "memory". But we could
    remove the smp_mb__after/before... case making it a smb_mb__across... if you
    think it's too much finegrined. I thought it was good to remain finegrined and
    the current macro names are also quite self-documenting.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:45    [W:0.022 / U:30.676 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site