All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: linux-riscv <linux-riscv@lists.infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>, Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Arnd Bergmann <arnd@arndb.de>,
	Jisheng Zhang <jszhang@kernel.org>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Openrisc <openrisc@lists.librecores.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 0/5] Generic Ticket Spinlocks
Date: Thu, 17 Mar 2022 10:16:50 +0100	[thread overview]
Message-ID: <CAK8P3a0J3ViDWserQew2wt95Hnu6AHT5gmSxtUz0x5W2fWdxBA@mail.gmail.com> (raw)
In-Reply-To: <20220316232600.20419-1-palmer@rivosinc.com>

On Thu, Mar 17, 2022 at 12:25 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> Peter sent an RFC out about a year ago
> <https://lore.kernel.org/lkml/YHbBBuVFNnI4kjj3@hirez.programming.kicks-ass.net/>,
> but after a spirited discussion it looks like we lost track of things.
> IIRC there was broad consensus on this being the way to go, but there
> was a lot of discussion so I wasn't sure.  Given that it's been a year,
> I figured it'd be best to just send this out again formatted a bit more
> explicitly as a patch.
>
> This has had almost no testing (just a build test on RISC-V defconfig),
> but I wanted to send it out largely as-is because I didn't have a SOB
> from Peter on the code.  I had sent around something sort of similar in
> spirit, but this looks completely re-written.  Just to play it safe I
> wanted to send out almost exactly as it was posted.  I'd probably rename
> this tspinlock and tspinlock_types, as the mis-match kind of makes my
> eyes go funny, but I don't really care that much.  I'll also go through
> the other ports and see if there's any more candidates, I seem to
> remember there having been more than just OpenRISC but it's been a
> while.
>
> I'm in no big rush for this and given the complex HW dependencies I
> think it's best to target it for 5.19, that'd give us a full merge
> window for folks to test/benchmark it on their systems to make sure it's
> OK.  RISC-V has a forward progress guarantee so we should be safe, but
> these can always trip things up.

This all looks good to me, feel free to merge the asm-generic
bits through the riscv tree.

Regarding the naming, my preference would be to just use
this version in place of the (currently useless) asm-generic/spinlock.h,
and just naming it arch_spin_lock() etc.

This way, converting an architecture to the generic ticket lock can
be done simply by removing its custom asm/spinlock.h. Or it
could stay with the current name, but then have a new
asm-generic/spinlock.h that just includes both asm/ticket_lock.h
and asm/qrwlock.h.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: linux-riscv <linux-riscv@lists.infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jonas Bonn <jonas@southpole.se>,
	 Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	 Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Waiman Long <longman@redhat.com>,
	 Boqun Feng <boqun.feng@gmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	 Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,  Arnd Bergmann <arnd@arndb.de>,
	Jisheng Zhang <jszhang@kernel.org>,
	 Kefeng Wang <wangkefeng.wang@huawei.com>,
	Openrisc <openrisc@lists.librecores.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 0/5] Generic Ticket Spinlocks
Date: Thu, 17 Mar 2022 10:16:50 +0100	[thread overview]
Message-ID: <CAK8P3a0J3ViDWserQew2wt95Hnu6AHT5gmSxtUz0x5W2fWdxBA@mail.gmail.com> (raw)
In-Reply-To: <20220316232600.20419-1-palmer@rivosinc.com>

On Thu, Mar 17, 2022 at 12:25 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> Peter sent an RFC out about a year ago
> <https://lore.kernel.org/lkml/YHbBBuVFNnI4kjj3@hirez.programming.kicks-ass.net/>,
> but after a spirited discussion it looks like we lost track of things.
> IIRC there was broad consensus on this being the way to go, but there
> was a lot of discussion so I wasn't sure.  Given that it's been a year,
> I figured it'd be best to just send this out again formatted a bit more
> explicitly as a patch.
>
> This has had almost no testing (just a build test on RISC-V defconfig),
> but I wanted to send it out largely as-is because I didn't have a SOB
> from Peter on the code.  I had sent around something sort of similar in
> spirit, but this looks completely re-written.  Just to play it safe I
> wanted to send out almost exactly as it was posted.  I'd probably rename
> this tspinlock and tspinlock_types, as the mis-match kind of makes my
> eyes go funny, but I don't really care that much.  I'll also go through
> the other ports and see if there's any more candidates, I seem to
> remember there having been more than just OpenRISC but it's been a
> while.
>
> I'm in no big rush for this and given the complex HW dependencies I
> think it's best to target it for 5.19, that'd give us a full merge
> window for folks to test/benchmark it on their systems to make sure it's
> OK.  RISC-V has a forward progress guarantee so we should be safe, but
> these can always trip things up.

This all looks good to me, feel free to merge the asm-generic
bits through the riscv tree.

Regarding the naming, my preference would be to just use
this version in place of the (currently useless) asm-generic/spinlock.h,
and just naming it arch_spin_lock() etc.

This way, converting an architecture to the generic ticket lock can
be done simply by removing its custom asm/spinlock.h. Or it
could stay with the current name, but then have a new
asm-generic/spinlock.h that just includes both asm/ticket_lock.h
and asm/qrwlock.h.

      Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 0/5] Generic Ticket Spinlocks
Date: Thu, 17 Mar 2022 10:16:50 +0100	[thread overview]
Message-ID: <CAK8P3a0J3ViDWserQew2wt95Hnu6AHT5gmSxtUz0x5W2fWdxBA@mail.gmail.com> (raw)
In-Reply-To: <20220316232600.20419-1-palmer@rivosinc.com>

On Thu, Mar 17, 2022 at 12:25 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> Peter sent an RFC out about a year ago
> <https://lore.kernel.org/lkml/YHbBBuVFNnI4kjj3@hirez.programming.kicks-ass.net/>,
> but after a spirited discussion it looks like we lost track of things.
> IIRC there was broad consensus on this being the way to go, but there
> was a lot of discussion so I wasn't sure.  Given that it's been a year,
> I figured it'd be best to just send this out again formatted a bit more
> explicitly as a patch.
>
> This has had almost no testing (just a build test on RISC-V defconfig),
> but I wanted to send it out largely as-is because I didn't have a SOB
> from Peter on the code.  I had sent around something sort of similar in
> spirit, but this looks completely re-written.  Just to play it safe I
> wanted to send out almost exactly as it was posted.  I'd probably rename
> this tspinlock and tspinlock_types, as the mis-match kind of makes my
> eyes go funny, but I don't really care that much.  I'll also go through
> the other ports and see if there's any more candidates, I seem to
> remember there having been more than just OpenRISC but it's been a
> while.
>
> I'm in no big rush for this and given the complex HW dependencies I
> think it's best to target it for 5.19, that'd give us a full merge
> window for folks to test/benchmark it on their systems to make sure it's
> OK.  RISC-V has a forward progress guarantee so we should be safe, but
> these can always trip things up.

This all looks good to me, feel free to merge the asm-generic
bits through the riscv tree.

Regarding the naming, my preference would be to just use
this version in place of the (currently useless) asm-generic/spinlock.h,
and just naming it arch_spin_lock() etc.

This way, converting an architecture to the generic ticket lock can
be done simply by removing its custom asm/spinlock.h. Or it
could stay with the current name, but then have a new
asm-generic/spinlock.h that just includes both asm/ticket_lock.h
and asm/qrwlock.h.

      Arnd

  parent reply	other threads:[~2022-03-17  9:17 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 23:25 [PATCH 0/5] Generic Ticket Spinlocks Palmer Dabbelt
2022-03-16 23:25 ` [OpenRISC] " Palmer Dabbelt
2022-03-16 23:25 ` Palmer Dabbelt
2022-03-16 23:25 ` [PATCH 1/5] asm-generic: qspinlock: Indicate the use of mixed-size atomics Palmer Dabbelt
2022-03-16 23:25   ` [OpenRISC] " Palmer Dabbelt
2022-03-16 23:25   ` Palmer Dabbelt
2022-03-17 17:46   ` Waiman Long
2022-03-17 17:46     ` [OpenRISC] " Waiman Long
2022-03-17 17:46     ` Waiman Long
2022-03-16 23:25 ` [PATCH 2/5] asm-generic: ticket-lock: New generic ticket-based spinlock Palmer Dabbelt
2022-03-16 23:25   ` [OpenRISC] " Palmer Dabbelt
2022-03-16 23:25   ` Palmer Dabbelt
2022-03-17  9:46   ` Peter Zijlstra
2022-03-17  9:46     ` [OpenRISC] " Peter Zijlstra
2022-03-17  9:46     ` Peter Zijlstra
2022-03-17 13:57   ` Boqun Feng
2022-03-17 13:57     ` [OpenRISC] " Boqun Feng
2022-03-17 13:57     ` Boqun Feng
2022-03-17 15:03     ` Waiman Long
2022-03-17 15:03       ` [OpenRISC] " Waiman Long
2022-03-17 15:03       ` Waiman Long
2022-03-17 15:34       ` Boqun Feng
2022-03-17 15:34         ` [OpenRISC] " Boqun Feng
2022-03-17 15:34         ` Boqun Feng
2022-03-17 18:04   ` Waiman Long
2022-03-17 18:04     ` [OpenRISC] " Waiman Long
2022-03-17 18:04     ` Waiman Long
2022-03-16 23:25 ` [PATCH 3/5] openrisc: Move to ticket-spinlock Palmer Dabbelt
2022-03-16 23:25   ` [OpenRISC] " Palmer Dabbelt
2022-03-16 23:25   ` Palmer Dabbelt
2022-03-17  9:46   ` Peter Zijlstra
2022-03-17  9:46     ` [OpenRISC] " Peter Zijlstra
2022-03-17  9:46     ` Peter Zijlstra
2022-03-21 21:29   ` Stafford Horne
2022-03-21 21:29     ` [OpenRISC] " Stafford Horne
2022-03-21 21:29     ` Stafford Horne
2022-03-22  3:29     ` Guo Ren
2022-03-22  3:29       ` [OpenRISC] " Guo Ren
2022-03-22  3:29       ` Guo Ren
2022-03-22  4:10       ` Stafford Horne
2022-03-22  4:10         ` [OpenRISC] " Stafford Horne
2022-03-22  4:10         ` Stafford Horne
2022-03-22  6:45         ` Guo Ren
2022-03-22  6:45           ` [OpenRISC] " Guo Ren
2022-03-22  6:45           ` Guo Ren
2022-03-16 23:25 ` [PATCH 4/5] RISC-V: Move to ticket-spinlocks Palmer Dabbelt
2022-03-16 23:25   ` [OpenRISC] " Palmer Dabbelt
2022-03-16 23:25   ` Palmer Dabbelt
2022-03-16 23:26 ` [PATCH 5/5] RISC-V: Move to queued RW locks Palmer Dabbelt
2022-03-16 23:26   ` [OpenRISC] " Palmer Dabbelt
2022-03-16 23:26   ` Palmer Dabbelt
2022-03-17  9:47   ` Peter Zijlstra
2022-03-17  9:47     ` [OpenRISC] " Peter Zijlstra
2022-03-17  9:47     ` Peter Zijlstra
2022-03-17  9:16 ` Arnd Bergmann [this message]
2022-03-17  9:16   ` [OpenRISC] [PATCH 0/5] Generic Ticket Spinlocks Arnd Bergmann
2022-03-17  9:16   ` Arnd Bergmann
2022-03-17 11:09 ` Heiko Stübner
2022-03-17 11:09   ` [OpenRISC] " Heiko =?unknown-8bit?q?St=C3=BCbner?=
2022-03-17 11:09   ` Heiko Stübner
2022-03-18  7:24   ` Guo Ren
2022-03-18  7:24     ` [OpenRISC] " Guo Ren
2022-03-18  7:24     ` Guo Ren
2022-03-18  8:40 ` Guo Ren
2022-03-18  8:40   ` [OpenRISC] " Guo Ren
2022-03-18  8:40   ` Guo Ren
2022-03-22 18:18 ` Conor Dooley
2022-03-22 18:18   ` [OpenRISC] " Conor Dooley
2022-03-22 18:18   ` Conor Dooley
2022-03-22 20:02   ` Palmer Dabbelt
2022-03-22 20:02     ` [OpenRISC] " Palmer Dabbelt
2022-03-22 20:02     ` Palmer Dabbelt
2022-03-22 20:19     ` Conor Dooley
2022-03-22 20:19       ` [OpenRISC] " Conor Dooley
2022-03-22 20:19       ` Conor Dooley

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=CAK8P3a0J3ViDWserQew2wt95Hnu6AHT5gmSxtUz0x5W2fWdxBA@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=aou@eecs.berkeley.edu \
    --cc=boqun.feng@gmail.com \
    --cc=jonas@southpole.se \
    --cc=jszhang@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=openrisc@lists.librecores.org \
    --cc=palmer@dabbelt.com \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=shorne@gmail.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=wangkefeng.wang@huawei.com \
    --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: link
Be 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.