Re: [PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3

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

 



Hi, Peter and Paul,

Loongson-3's Store Fill Buffer is nearly the same as your "Store Buffer", and it increases the memory ordering weakness. So, smp_cond_load_acquire() only need a __smp_mb() before the loop, not after every READ_ONCE(). In other word, the following code is just OK:

#define smp_cond_load_acquire(ptr, cond_expr)                   \
({                                                              \
        typeof(ptr) __PTR = (ptr);                              \
        typeof(*ptr) VAL;                                       \
        __smp_mb();                                     \
        for (;;) {                                              \
                VAL = READ_ONCE(*__PTR);                        \
                if (cond_expr)                                  \
                        break;                                  \
                cpu_relax();                                    \
        }                                                       \
        __smp_mb();                                     \
        VAL;                                                    \
})

the __smp_mb() before loop is used to avoid "reads prioritised over writes", which is caused by SFB's weak ordering and similar to ARM11MPCore (mentioned by Will Deacon).

Huacai

------------------ Original ------------------
From:  "Peter Zijlstra"<peterz@xxxxxxxxxxxxx>;
Date:  Tue, Jun 19, 2018 03:22 PM
To:  "陈华才"<chenhc@xxxxxxxxxx>;
Cc:  "Paul Burton"<paul.burton@xxxxxxxx>; "Ralf Baechle"<ralf@xxxxxxxxxxxxxx>; "James Hogan"<james.hogan@xxxxxxxx>; "linux-mips"<linux-mips@xxxxxxxxxxxxxx>; "Fuxin Zhang"<zhangfx@xxxxxxxxxx>; "wuzhangjin"<wuzhangjin@xxxxxxxxx>; "Huacai Chen"<chenhuacai@xxxxxxxxx>; "stable"<stable@xxxxxxxxxxxxxxx>; "Alan Stern"<stern@xxxxxxxxxxxxxxxxxxx>; "AndreaParri"<andrea.parri@xxxxxxxxxxxxxxxxxxxx>; "Will Deacon"<will.deacon@xxxxxxx>; "Boqun Feng"<boqun.feng@xxxxxxxxx>; "Nicholas Piggin"<npiggin@xxxxxxxxx>; "David Howells"<dhowells@xxxxxxxxxx>; "Jade Alglave"<j.alglave@xxxxxxxxx>; "Luc Maranget"<luc.maranget@xxxxxxxx>; "Paul E. McKenney"<paulmck@xxxxxxxxxxxxxxxxxx>; "Akira Yokosawa"<akiyks@xxxxxxxxx>; "linux-kernel"<linux-kernel@xxxxxxxxxxxxxxx>;
Subject:  Re: [PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3
 
On Tue, Jun 19, 2018 at 02:40:14PM +0800, 陈华才 wrote:
> Hi, Paul,
> 
> First of all, could you please check why linux-mips reject e-mails
> from lemote.com? Of course I can send e-mails by gmail, but my gmail
> can't receive e-mails from linux-mips since March, 2018.

Could you please learn to use email? No top posting and wrap lines at 78
chars.

> I have already read Documentation/memory-barriers.txt, but I don't
> think we should define a smp_read_barrier_depends() for Loongson-3.
> Because Loongson-3's behavior isn't like Alpha, and in syntax, this is
> not a data-dependent issue.

Agreed, this is not a data-dependency issue.

> There is no document about Loongson-3's SFB. In my opinion, SFB looks
> like the L0 cache but sometimes it is out of cache-coherent machanism
> (L1 cache's cross-core coherency is maintained by hardware, but not
> always true for SFB). smp_mb() is needed for smp_cond_load_acquire(),
> but not every READ_ONCE().

Linux does _NOT_ support non-coherent SMP. If your system is not fully
coherent, you're out of luck.

But please, explain in excruciating detail what exactly you need that
smp_mb for. If, like I posited in my previous email, it is to ensure
remote store buffer flushes, then your machine is terminally broken.




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux