On Wed, Apr 7, 2021 at 6:00 PM Peter Zijlstra wrote:
>
> On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> > RISC-V defines LR/SC loops consisting of up to 16 instructions as
> > constrained LR/SC loops. Such constrained LR/SC loops provide the
> > required forward guarantees,
On Wed, Apr 07, 2021 at 05:52:36PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> > The comparison with sparc64 is not applicable, as sparc64 does not
> > have LL/SC instructions.
>
> Sparc64 has CAS, without hardware fwd progress. It has to do
On Wed, Apr 07, 2021 at 05:51:07PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> > Further, it is not the case that RISC-V has no guarantees at all.
> > It just does not provide a forward progress guarantee for a
> > synchronization
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> RISC-V defines LR/SC loops consisting of up to 16 instructions as
> constrained LR/SC loops. Such constrained LR/SC loops provide the
> required forward guarantees, that are expected (similar to what other
> architectures, like
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> The comparison with sparc64 is not applicable, as sparc64 does not
> have LL/SC instructions.
Sparc64 has CAS, without hardware fwd progress. It has to do software
backoff for failed CAS in order to do software fwd progress.
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> Further, it is not the case that RISC-V has no guarantees at all.
> It just does not provide a forward progress guarantee for a
> synchronization implementation,
> that writes in an endless loop to a memory location while trying
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph M??llner wrote:
> Gentlemen, please rethink your wording.
> RISC-V is neither "crap" nor a "trainwreck", regardless if you like it or not.
No, by all objective standards the RISC-V memory model and privileged
architecture is a trainwreck.
On Wed, Apr 7, 2021 at 11:43 AM Christoph Hellwig wrote:
>
> On Tue, Apr 06, 2021 at 09:15:50AM +0200, Peter Zijlstra wrote:
> > Anyway, given you have such a crap architecture (and here I thought
> > RISC-V was supposed to be a modern design *sigh*), you had better go
> > look at the sparc64
On Wed, Apr 07, 2021 at 01:36:45PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 07, 2021 at 10:42:50AM +0200, Arnd Bergmann wrote:
> > Since there are really only a handful of instances in the kernel
> > that use the cmpxchg() or xchg() on u8/u16 variables, it would seem
> > best to just disallow
On Wed, Apr 7, 2021 at 1:36 PM Peter Zijlstra wrote:
>
> On Wed, Apr 07, 2021 at 10:42:50AM +0200, Arnd Bergmann wrote:
> > Since there are really only a handful of instances in the kernel
> > that use the cmpxchg() or xchg() on u8/u16 variables, it would seem
> > best to just disallow those
On Wed, Apr 07, 2021 at 10:42:50AM +0200, Arnd Bergmann wrote:
> Since there are really only a handful of instances in the kernel
> that use the cmpxchg() or xchg() on u8/u16 variables, it would seem
> best to just disallow those completely
Not going to happen. xchg16 is optimal for qspinlock
On Tue, Apr 06, 2021 at 09:15:50AM +0200, Peter Zijlstra wrote:
> Anyway, given you have such a crap architecture (and here I thought
> RISC-V was supposed to be a modern design *sigh*), you had better go
> look at the sparc64 atomic implementation which has a software backoff
> for failed CAS in
On Wed, Apr 07, 2021 at 01:24:12AM +0800, Boqun Feng wrote:
> Actually, "old" riscv standard does provide fwd progress ;-) In
>
> https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
>
> Section "7.2 Load-Reserved/Store-Conditional Instructions":
>
> """
> One advantage of
On Tue, Apr 6, 2021 at 10:56 AM Stafford Horne wrote:
> On Tue, Apr 06, 2021 at 11:50:38AM +0800, Guo Ren wrote:
> > On Wed, Mar 31, 2021 at 3:23 PM Arnd Bergmann wrote:
> > > On Wed, Mar 31, 2021 at 12:35 AM Stafford Horne wrote:
> >
> > We shouldn't export xchg16/cmpxchg16(emulated by
On Wed, Mar 31, 2021 at 11:22:35PM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa66bb;
> > > u16 *ptr =
> > >
> > > CPU0 CPU1
> > > =
On Tue, Apr 06, 2021 at 11:50:38AM +0800, Guo Ren wrote:
> On Wed, Mar 31, 2021 at 3:23 PM Arnd Bergmann wrote:
> >
> > On Wed, Mar 31, 2021 at 12:35 AM Stafford Horne wrote:
> > >
> > > I just want to chime in here, there may be a better spot in the thread to
> > > mention this but, for
On Wed, Mar 31, 2021 at 11:10:53PM +0800, Guo Ren wrote:
> Hi Stafford,
>
> How do think add ARCH_USE_QUEUED_SPINLOCKS_XCHG32 in openrisc?
>
> https://lore.kernel.org/linux-riscv/1617201040-83905-7-git-send-email-guo...@kernel.org/T/#u
Sorry I missed your mail here.
It is true that OpenRISC
On Wed, Mar 31, 2021 at 11:22:35PM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa66bb;
> > > u16 *ptr =
> > >
> > > CPU0 CPU1
> > > =
On Wed, Mar 31, 2021 at 3:23 PM Arnd Bergmann wrote:
>
> On Wed, Mar 31, 2021 at 12:35 AM Stafford Horne wrote:
> >
> > I just want to chime in here, there may be a better spot in the thread to
> > mention this but, for OpenRISC I did implement some generic 8/16-bit xchg
> > code
> > which I
On Tue, Mar 30, 2021 at 10:09 PM Waiman Long wrote:
>
> On 3/29/21 11:13 PM, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >> On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> >>> u32 a = 0x55aa66bb;
> >>> u16 *ptr =
> >>>
> >>> CPU0
On Wed, Mar 31, 2021 at 12:08 AM Peter Zijlstra wrote:
>
> On Tue, Mar 30, 2021 at 11:13:55AM +0800, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > > u32 a = 0x55aa66bb;
> > > > u16 *ptr =
> > >
Hi Paul,
Thx for the explanation, here is my comment.
On Wed, Mar 31, 2021 at 1:33 PM Paul Campbell wrote:
>
> On Wednesday, 31 March 2021 5:18:56 PM NZDT Guo Ren wrote:
> > > > [1]
> > > > https://github.com/c-sky/csky-linux/commit/e837aad23148542771794d8a2fcc
> > > > 52afd0fcbf88> >
> > > > >
On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
>
> On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > u32 a = 0x55aa66bb;
> > u16 *ptr =
> >
> > CPU0 CPU1
> > = =
> > xchg16(ptr, new) while(1)
> >
Hi Stafford,
How do think add ARCH_USE_QUEUED_SPINLOCKS_XCHG32 in openrisc?
https://lore.kernel.org/linux-riscv/1617201040-83905-7-git-send-email-guo...@kernel.org/T/#u
On Wed, Mar 31, 2021 at 8:31 PM Stafford Horne wrote:
>
> On Wed, Mar 31, 2021 at 09:23:27AM +0200, Arnd Bergmann wrote:
> >
On Tue, Mar 30, 2021 at 10:09 PM Waiman Long wrote:
>
> On 3/29/21 11:13 PM, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >> On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> >>> u32 a = 0x55aa66bb;
> >>> u16 *ptr =
> >>>
> >>> CPU0
On Wed, Mar 31, 2021 at 09:23:27AM +0200, Arnd Bergmann wrote:
> On Wed, Mar 31, 2021 at 12:35 AM Stafford Horne wrote:
> >
> > I just want to chime in here, there may be a better spot in the thread to
> > mention this but, for OpenRISC I did implement some generic 8/16-bit xchg
> > code
> >
On Wed, Mar 31, 2021 at 12:35 AM Stafford Horne wrote:
>
> I just want to chime in here, there may be a better spot in the thread to
> mention this but, for OpenRISC I did implement some generic 8/16-bit xchg code
> which I have on my todo list somwhere to replace the other generic
>
On Wed, Mar 31, 2021 at 8:44 AM Guo Ren wrote:
> On Wed, Mar 31, 2021 at 12:18 PM Guo Ren wrote:
> > On Tue, Mar 30, 2021 at 3:12 PM Arnd Bergmann wrote:
> > > On Tue, Mar 30, 2021 at 4:26 AM Guo Ren wrote:
> > > As I understand, this example must not cause a deadlock on
> > > a compliant
Hi Arnd
On Wed, Mar 31, 2021 at 12:18 PM Guo Ren wrote:
>
> On Tue, Mar 30, 2021 at 3:12 PM Arnd Bergmann wrote:
> >
> > On Tue, Mar 30, 2021 at 4:26 AM Guo Ren wrote:
> > > On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
> > > > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> > > > >
On Wednesday, 31 March 2021 5:18:56 PM NZDT Guo Ren wrote:
> > > [1]
> > > https://github.com/c-sky/csky-linux/commit/e837aad23148542771794d8a2fcc
> > > 52afd0fcbf88> >
> > > > It also seems that the current "amoswap" based implementation
> > > > would be reliable independent of
On Tue, Mar 30, 2021 at 3:12 PM Arnd Bergmann wrote:
>
> On Tue, Mar 30, 2021 at 4:26 AM Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
> > > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> > > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra
> > > > wrote:
> > > >
On Tue, Mar 30, 2021 at 06:08:40PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 30, 2021 at 11:13:55AM +0800, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > > u32 a = 0x55aa66bb;
> > > > u16 *ptr =
On Tue, Mar 30, 2021 at 11:13:55AM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa66bb;
> > > u16 *ptr =
> > >
> > > CPU0 CPU1
> > > =
On 3/29/21 11:13 PM, Guo Ren wrote:
On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
u32 a = 0x55aa66bb;
u16 *ptr =
CPU0 CPU1
= =
xchg16(ptr, new) while(1)
From: Guo Ren
> Sent: 30 March 2021 04:14
...
> > Step 1 would be to get your architecute fixed such that it can provide
> > fwd progress guarantees for LL/SC. Otherwise there's absolutely no point
> > in building complex systems with it.
>
> Quote Waiman's comment [1] on xchg16 optimization:
>
On Tue, Mar 30, 2021 at 4:26 AM Guo Ren wrote:
> On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
> > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra
> > > wrote:
> > > >
> > > > What's the architectural guarantee on LL/SC progress for
x-arch
> > ; Guo Ren ; Will
> > Deacon ; Ingo Molnar ; Waiman
> > Long ; Arnd Bergmann ; Anup
> > Patel
> > Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add
> > ARCH_USE_QUEUED_SPINLOCKS_XCHG32
> >
> > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra
On Tue, Mar 30, 2021 at 1:51 PM Anup Patel wrote:
>
> On Tue, Mar 30, 2021 at 7:56 AM Guo Ren wrote:
> >
> > On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
> > >
> > > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> > > >
> > > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra
> > > >
On Tue, Mar 30, 2021 at 7:56 AM Guo Ren wrote:
>
> On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
> >
> > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> > >
> > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra
> > > wrote:
> > > >
> > > > On Mon, Mar 29, 2021 at 01:16:53PM +0200,
; Patel
> Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add
> ARCH_USE_QUEUED_SPINLOCKS_XCHG32
>
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra
> wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa6
On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
>
> On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > u32 a = 0x55aa66bb;
> > u16 *ptr =
> >
> > CPU0 CPU1
> > = =
> > xchg16(ptr, new) while(1)
> >
On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
>
> On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> >
> > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> > > > Anyway, an additional 'funny' is that I
On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
>
> On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra wrote:
> >
> > On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> > > Anyway, an additional 'funny' is that I suspect you cannot prove fwd
> > > progress of the entire primitive with
On Mon, Mar 29, 2021 at 12:13:10PM +, Anup Patel wrote:
> We had discussions in the RISC-V platforms group about this. Over there,
> We had evaluated all spin lock approaches (ticket, qspinlock, etc) tried
> in Linux till now. It was concluded in those discussions that eventually we
> have to
On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra wrote:
>
> On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> > Anyway, an additional 'funny' is that I suspect you cannot prove fwd
> > progress of the entire primitive with any of this on. But who cares
> > about details anyway.. :/
On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> u32 a = 0x55aa66bb;
> u16 *ptr =
>
> CPU0 CPU1
> = =
> xchg16(ptr, new) while(1)
> WRITE_ONCE(*(ptr + 1), x);
>
> When we use lr.w/sc.w implement
Anup
> Patel
> Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add
> ARCH_USE_QUEUED_SPINLOCKS_XCHG32
>
> On Mon, Mar 29, 2021 at 07:19:29PM +0800, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 3:50 PM Peter Zijlstra
> wrote:
> > >
> > > On Sat, Mar 27, 202
On Mon, Mar 29, 2021 at 7:26 PM Peter Zijlstra wrote:
>
> On Mon, Mar 29, 2021 at 07:19:29PM +0800, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 3:50 PM Peter Zijlstra wrote:
> > >
> > > On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> > > > From: Guo Ren
> > > >
> > > > Some
On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> Anyway, an additional 'funny' is that I suspect you cannot prove fwd
> progress of the entire primitive with any of this on. But who cares
> about details anyway.. :/
What's the architectural guarantee on LL/SC progress for RISC-V
On Mon, Mar 29, 2021 at 07:19:29PM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 3:50 PM Peter Zijlstra wrote:
> >
> > On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> > > From: Guo Ren
> > >
> > > Some architectures don't have sub-word swap atomic instruction,
> > > they
On Mon, Mar 29, 2021 at 3:50 PM Peter Zijlstra wrote:
>
> On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Some architectures don't have sub-word swap atomic instruction,
> > they only have the full word's one.
> >
> > The sub-word swap only improve
On Mon, Mar 29, 2021 at 11:41:19AM +0200, Arnd Bergmann wrote:
> On Mon, Mar 29, 2021 at 9:52 AM Peter Zijlstra wrote:
> > On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> > > From: Guo Ren
> > >
> > > Some architectures don't have sub-word swap atomic instruction,
> > > they
On Mon, Mar 29, 2021 at 9:52 AM Peter Zijlstra wrote:
> On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Some architectures don't have sub-word swap atomic instruction,
> > they only have the full word's one.
> >
> > The sub-word swap only improve the
On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> From: Guo Ren
>
> Some architectures don't have sub-word swap atomic instruction,
> they only have the full word's one.
>
> The sub-word swap only improve the performance when:
> NR_CPUS < 16K
> * 0- 7: locked byte
> *
On Sun, Mar 28, 2021 at 2:43 AM Waiman Long wrote:
>
> On 3/27/21 2:06 PM, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Some architectures don't have sub-word swap atomic instruction,
> > they only have the full word's one.
> >
> > The sub-word swap only improve the performance when:
> >
On 3/27/21 2:06 PM, guo...@kernel.org wrote:
From: Guo Ren
Some architectures don't have sub-word swap atomic instruction,
they only have the full word's one.
The sub-word swap only improve the performance when:
NR_CPUS < 16K
* 0- 7: locked byte
* 8: pending
* 9-15: not used
*
56 matches
Mail list logo
