lkml.org 
[lkml]   [2009]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv5 2/2] memory barrier: adding smp_mb__after_lock
    On Tue, Jul 07, 2009 at 05:23:18PM +0200, Eric Dumazet wrote:
    > Mathieu Desnoyers a écrit :
    >
    > > But read_lock + smp_mb__after_lock + read_unlock is not well suited for
    > > powerpc, arm, mips and probably others where there is an explicit memory
    > > barrier at the end of the read lock primitive.
    > >
    > > One thing that would be efficient for all architectures is to create a
    > > locking primitive that contains the smp_mb, e.g.:
    > >
    > > read_lock_smp_mb()
    > >
    > > which would act as a read_lock which does a full smp_mb after the lock
    > > is taken.
    > >
    > > The naming may be a bit odd, better ideas are welcome.
    >
    > I see your point now, thanks for your patience.
    >
    > Jiri, I think your first patch can be applied (including the full smp_mb()),
    > then we will optimize both for x86 and other arches, when all
    > arch maintainers have a chance to change
    > "read_lock();smp_mb()" to a faster "read_lock_mb()" or something :)
    >

    great, I saw you Signed-off the 1/2 part.. could I leave it,
    or do I need to resend as a single patch?

    jirka
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-07-08 19:51    [W:4.209 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site