From: Huang Pei <email@example.com> To: firstname.lastname@example.org Cc: Paul Burton <email@example.com>, jhogan <firstname.lastname@example.org>, "jiaxun.yang" <email@example.com>, linux-mips <firstname.lastname@example.org> Subject: Re: Something about loongson_llsc_mb Date: Wed, 4 Sep 2019 20:57:38 +0800 Message-ID: <email@example.com> (raw) In-Reply-To: <20190904092154.GC2349@hirez.programming.kicks-ass.net> On 09/04/2019 05:21 PM, Peter Zijlstra wrote: > > *why* are you replying to some random unrelated thread? Chen ask me if whether your patch has more sync than needed, but I'm not sure whether sync before and after *cmpxchg_local* is. > > Also, please use a sane MUA and wrap your lines <80 chars. Sorry, I finally got thunderbird in plain text mode with < 80 chars. It wont happen again. > > On Wed, Sep 04, 2019 at 10:03:31AM +0800, firstname.lastname@example.org wrote: >>> Hi, Peter, >>> >>> I found that this patch has been merged but I haven't received the e-mail for some unknown reasons. >>> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=1c6c1ca318585f1096d4d04bc722297c85e9fb8a >>> >>> Firstly, your comments are correct, so the barrier.h part is perfect. >>> >>> Secondly, most of the rest is useless, because smp_mb__before_llsc, loongson_llsc_mb and other memory barriers are the same thing on Loongson-3. We don't need to add loongson_llsc_mb if there is already a smp_mb__before_llsc. > > There wasn't. Take for example set_bit(), that didn't have > smp_mb__before_llsc on. > > Also; MIPS should probably convert to asm-generic/bitops/atomic.h. > >>> Thirdly, maybe the only exception is syscall.c, but mips_atomic_set is not used on Loongson-3. And if in some cases we use it, I think the user-to-kernel context switch has the same effect of a memory barrier. > > And how is some random person trying to make sense of MIPS to know that? > > You all created a badly documented inconsitent trainwreck. You're > 'lucky' the MIPS maintainers accepted that mess in the first place. > > Anyway, yes there are too many barrers now in some cases, in a previous > version I had: > > https://email@example.com > > But because I dropped changes to local.h that might not be true anymore; > it needs careful consideration. Please audit carefully and if you find > all smp_mb__before_llsc() usage is now superfluous for this 'funny' chip > of yours, then re-submit the above patch. > >> +. per-cpu like local_t *should only* be written by local cpu, and may be read by remote cpu sometimes >> >> +. if and only if local cpu can write per-cpu, then Loongson3's llsc bug would not be triggerd. >> >> same as this_cpu_cmpxchg_double >> >> If so, then no need to add sync before and after cmpxchg_local > > Correct, we already dropped the change for other local.h stuff. > What about cmpxchg_local? Your patch add sync before and after ll/sc in __cmpxchg, so *cmpxchg_local* has sync around it. But cmpxchg_local operate on per-cpu, which *shall not* trigger loongson's LLSC bug, since only *this* cpu write, other cpus read.
next prev parent reply index Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-31 5:58 [PATCH v2 0/9] check the node id consistently across different arches Yunsheng Lin 2019-08-31 5:58 ` [PATCH v2 1/9] arm64: numa: check the node id consistently for arm64 Yunsheng Lin 2019-08-31 5:58 ` [PATCH v2 2/9] x86: numa: check the node id consistently for x86 Yunsheng Lin 2019-08-31 8:55 ` Peter Zijlstra 2019-08-31 10:09 ` Yunsheng Lin 2019-08-31 16:12 ` Peter Zijlstra 2019-09-01 4:45 ` Something about loongson_llsc_mb 陈华才 [not found] ` <firstname.lastname@example.org> 2019-09-04 9:21 ` Peter Zijlstra 2019-09-04 10:04 ` Peter Zijlstra 2019-09-04 12:57 ` Huang Pei [this message] 2019-09-02 5:46 ` [PATCH v2 2/9] x86: numa: check the node id consistently for x86 Yunsheng Lin 2019-09-02 7:25 ` Peter Zijlstra 2019-09-02 12:25 ` Yunsheng Lin 2019-09-02 12:56 ` Peter Zijlstra 2019-09-02 18:22 ` Ingo Molnar 2019-09-02 19:14 ` Peter Zijlstra 2019-09-03 6:19 ` Yunsheng Lin 2019-09-03 7:11 ` Peter Zijlstra 2019-09-03 8:31 ` Yunsheng Lin 2019-09-02 18:17 ` Ingo Molnar 2019-09-03 7:53 ` [PATCH] x86/mm: Fix cpumask_of_node() error condition Peter Zijlstra 2019-08-31 5:58 ` [PATCH v2 3/9] alpha: numa: check the node id consistently for alpha Yunsheng Lin 2019-08-31 5:58 ` [PATCH v2 4/9] powerpc: numa: check the node id consistently for powerpc Yunsheng Lin 2019-08-31 5:58 ` [PATCH v2 5/9] s390: numa: check the node id consistently for s390 Yunsheng Lin 2019-09-02 4:05 ` kbuild test robot 2019-08-31 5:58 ` [PATCH v2 6/9] sh: numa: check the node id consistently for sh Yunsheng Lin 2019-08-31 5:58 ` [PATCH v2 7/9] sparc64: numa: check the node id consistently for sparc64 Yunsheng Lin 2019-08-31 6:53 ` David Miller 2019-08-31 8:57 ` Yunsheng Lin 2019-08-31 20:02 ` David Miller 2019-09-02 6:08 ` Yunsheng Lin 2019-09-02 15:17 ` David Miller 2019-08-31 5:58 ` [PATCH v2 8/9] mips: numa: check the node id consistently for mips ip27 Yunsheng Lin 2019-08-31 5:58 ` [PATCH v2 9/9] mips: numa: check the node id consistently for mips loongson64 Yunsheng Lin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-MIPS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mips/0 linux-mips/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mips linux-mips/ https://lore.kernel.org/linux-mips \ firstname.lastname@example.org public-inbox-index linux-mips Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-mips AGPL code for this site: git clone https://public-inbox.org/public-inbox.git