From: Guo Ren <guoren@kernel.org> To: Andrea Parri <parri.andrea@gmail.com> Cc: Boqun Feng <boqun.feng@gmail.com>, Daniel Lustig <dlustig@nvidia.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Arnd Bergmann <arnd@arndb.de>, Palmer Dabbelt <palmer@dabbelt.com>, Mark Rutland <mark.rutland@arm.com>, Will Deacon <will@kernel.org>, Peter Zijlstra <peterz@infradead.org>, linux-arch <linux-arch@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org>, Guo Ren <guoren@linux.alibaba.com> Subject: Re: [PATCH V2 0/3] riscv: atomic: Optimize AMO instructions usage Date: Sun, 24 Apr 2022 16:33:53 +0800 [thread overview] Message-ID: <CAJF2gTSmVa9iKzojvrrQghkzBZao4eQwKBTKQfSPFqSR667bTg@mail.gmail.com> (raw) In-Reply-To: <20220418234137.GA444607@anparri> On Tue, Apr 19, 2022 at 7:41 AM Andrea Parri <parri.andrea@gmail.com> wrote: > > > > Seems to me that you are basically reverting 5ce6c1f3535f > > > ("riscv/atomic: Strengthen implementations with fences"). That commit > > > fixed an memory ordering issue, could you explain why the issue no > > > longer needs a fix? > > > > I'm not reverting the prior patch, just optimizing it. > > > > In RISC-V “A” Standard Extension for Atomic Instructions spec, it said: > > With reference to the RISC-V herd specification at: > > https://github.com/riscv/riscv-isa-manual.git > > the issue, better, lr-sc-aqrl-pair-vs-full-barrier seems to _no longer_ > need a fix since commit: "0: lr.w %0, %2\n" \ " bne %0, %z3, 1f\n" \ " sc.w.rl %1, %z4, %2\n" \ " bnez %1, 0b\n" \ " fence rw, rw\n" \ Above is the current implementation, and the logic is in conflict. If we want full-barrier, we should implement like below: fence rw, w "0: lr.w %0, %2\n" \ " bne %0, %z3, 1f\n" \ " sc.w %1, %z4, %2\n" \ " bnez %1, 0b\n" \ " fence rw, rw\n" \ Above we could let lr.w & sc.w executed fastest. If we think .aq/.rl won't affect forward guarantee, we should implement like below: "0: lr.w %0, %2\n" \ " bne %0, %z3, 1f\n" \ " sc.w.aqrl %1, %z4, %2\n" \ " bnez %1, 0b\n" \ Using .aqrl is better than sc.w.rl + fence rw, rw, because lr/sc.rl pair forward guarantee is the same with lr/sw.aqrl and only sc.rl part would affect the speed of lr/sc speed. Second, it could reduce one fence rw, rw overhead. So for riscv, we needn't put a full-barrier after sc like arm64 and use .aqrl instead. > > 03a5e722fc0f ("Updates to the memory consistency model spec") > > (here a template, to double check: > > https://github.com/litmus-tests/litmus-tests-riscv/blob/master/tests/non-mixed-size/HAND/LR-SC-NOT-FENCE.litmus ) > > I defer to Daniel/others for a "bi-section" of the prose specification. > ;-) > > Andrea -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
WARNING: multiple messages have this Message-ID (diff)
From: Guo Ren <guoren@kernel.org> To: Andrea Parri <parri.andrea@gmail.com> Cc: Boqun Feng <boqun.feng@gmail.com>, Daniel Lustig <dlustig@nvidia.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Arnd Bergmann <arnd@arndb.de>, Palmer Dabbelt <palmer@dabbelt.com>, Mark Rutland <mark.rutland@arm.com>, Will Deacon <will@kernel.org>, Peter Zijlstra <peterz@infradead.org>, linux-arch <linux-arch@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org>, Guo Ren <guoren@linux.alibaba.com> Subject: Re: [PATCH V2 0/3] riscv: atomic: Optimize AMO instructions usage Date: Sun, 24 Apr 2022 16:33:53 +0800 [thread overview] Message-ID: <CAJF2gTSmVa9iKzojvrrQghkzBZao4eQwKBTKQfSPFqSR667bTg@mail.gmail.com> (raw) In-Reply-To: <20220418234137.GA444607@anparri> On Tue, Apr 19, 2022 at 7:41 AM Andrea Parri <parri.andrea@gmail.com> wrote: > > > > Seems to me that you are basically reverting 5ce6c1f3535f > > > ("riscv/atomic: Strengthen implementations with fences"). That commit > > > fixed an memory ordering issue, could you explain why the issue no > > > longer needs a fix? > > > > I'm not reverting the prior patch, just optimizing it. > > > > In RISC-V “A” Standard Extension for Atomic Instructions spec, it said: > > With reference to the RISC-V herd specification at: > > https://github.com/riscv/riscv-isa-manual.git > > the issue, better, lr-sc-aqrl-pair-vs-full-barrier seems to _no longer_ > need a fix since commit: "0: lr.w %0, %2\n" \ " bne %0, %z3, 1f\n" \ " sc.w.rl %1, %z4, %2\n" \ " bnez %1, 0b\n" \ " fence rw, rw\n" \ Above is the current implementation, and the logic is in conflict. If we want full-barrier, we should implement like below: fence rw, w "0: lr.w %0, %2\n" \ " bne %0, %z3, 1f\n" \ " sc.w %1, %z4, %2\n" \ " bnez %1, 0b\n" \ " fence rw, rw\n" \ Above we could let lr.w & sc.w executed fastest. If we think .aq/.rl won't affect forward guarantee, we should implement like below: "0: lr.w %0, %2\n" \ " bne %0, %z3, 1f\n" \ " sc.w.aqrl %1, %z4, %2\n" \ " bnez %1, 0b\n" \ Using .aqrl is better than sc.w.rl + fence rw, rw, because lr/sc.rl pair forward guarantee is the same with lr/sw.aqrl and only sc.rl part would affect the speed of lr/sc speed. Second, it could reduce one fence rw, rw overhead. So for riscv, we needn't put a full-barrier after sc like arm64 and use .aqrl instead. > > 03a5e722fc0f ("Updates to the memory consistency model spec") > > (here a template, to double check: > > https://github.com/litmus-tests/litmus-tests-riscv/blob/master/tests/non-mixed-size/HAND/LR-SC-NOT-FENCE.litmus ) > > I defer to Daniel/others for a "bi-section" of the prose specification. > ;-) > > Andrea -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-04-24 8:34 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-12 3:49 [PATCH V2 0/3] riscv: atomic: Optimize AMO instructions usage guoren 2022-04-12 3:49 ` guoren 2022-04-12 3:49 ` [PATCH V2 1/3] riscv: atomic: Cleanup unnecessary definition guoren 2022-04-12 3:49 ` guoren 2022-04-12 3:49 ` [PATCH V2 2/3] riscv: atomic: Optimize acquire and release for AMO operations guoren 2022-04-12 3:49 ` guoren 2022-04-12 3:49 ` [PATCH V2 3/3] riscv: atomic: Optimize memory barrier semantics of LRSC-pairs guoren 2022-04-12 3:49 ` guoren 2022-04-13 15:46 ` [PATCH V2 0/3] riscv: atomic: Optimize AMO instructions usage Boqun Feng 2022-04-13 15:46 ` Boqun Feng 2022-04-16 16:49 ` Guo Ren 2022-04-16 16:49 ` Guo Ren 2022-04-17 2:26 ` Boqun Feng 2022-04-17 2:26 ` Boqun Feng 2022-04-17 4:51 ` Guo Ren 2022-04-17 4:51 ` Guo Ren 2022-04-17 6:30 ` Boqun Feng 2022-04-17 6:30 ` Boqun Feng 2022-04-17 6:45 ` Guo Ren 2022-04-17 6:45 ` Guo Ren 2022-04-19 17:12 ` Dan Lustig 2022-04-19 17:12 ` Dan Lustig 2022-04-20 5:33 ` Guo Ren 2022-04-20 5:33 ` Guo Ren 2022-04-20 17:03 ` Dan Lustig 2022-04-20 17:03 ` Dan Lustig 2022-04-21 9:39 ` Guo Ren 2022-04-21 9:39 ` Guo Ren 2022-04-21 22:56 ` Boqun Feng 2022-04-21 22:56 ` Boqun Feng 2022-04-22 1:56 ` Guo Ren 2022-04-22 1:56 ` Guo Ren 2022-04-22 3:11 ` Boqun Feng 2022-04-22 3:11 ` Boqun Feng 2022-04-24 7:52 ` Guo Ren 2022-04-24 7:52 ` Guo Ren 2022-04-18 23:41 ` Andrea Parri 2022-04-18 23:41 ` Andrea Parri 2022-04-19 17:13 ` Dan Lustig 2022-04-19 17:13 ` Dan Lustig 2022-04-24 8:33 ` Guo Ren [this message] 2022-04-24 8:33 ` Guo Ren
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 \ --in-reply-to=CAJF2gTSmVa9iKzojvrrQghkzBZao4eQwKBTKQfSPFqSR667bTg@mail.gmail.com \ --to=guoren@kernel.org \ --cc=arnd@arndb.de \ --cc=boqun.feng@gmail.com \ --cc=dlustig@nvidia.com \ --cc=guoren@linux.alibaba.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=mark.rutland@arm.com \ --cc=palmer@dabbelt.com \ --cc=parri.andrea@gmail.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=peterz@infradead.org \ --cc=will@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.