arch/riscv/Kconfig | 24 +++++++ arch/riscv/include/asm/cpuidle.h | 11 +--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/include/asm/processor.h | 31 +++++++++ arch/riscv/include/asm/smp.h | 14 ++++ arch/riscv/kernel/cpu.c | 5 ++ arch/riscv/kernel/cpufeature.c | 1 + arch/riscv/kernel/process.c | 102 ++++++++++++++++++++++++++++- arch/riscv/kernel/smp.c | 39 +++++++---- 9 files changed, 205 insertions(+), 23 deletions(-)
This patch series introduces a new implementation of idle thread using Zawrs extension. The Zawrs[0] extension introduces two new instructions named WRS.STO and WRS.NTO in RISC-V. When software registers a reservation set using LR instruction, a subsequent WRS.STO or WRS.NTO instruction will cause the hart to stall in a low-power state until a store happens to the reservation set or an interrupt becomes pending. The difference between these two instructions is that WRS.STO will terminate stall after an implementation-defined timeout while WRS.NTO won't. This patch series implements idle thread using WRS.NTO instruction. Besides, we found there is no need to send a real IPI to wake up an idle CPU. Instead, we write IPI information to the reservation set of an idle CPU to wake it up and let it handle IPI quickly, without going through tranditional interrupt handling routine. [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc Xu Lu (2): riscv: process: Introduce idle thread using Zawrs extension riscv: Use Zawrs to accelerate IPI to idle cpu arch/riscv/Kconfig | 24 +++++++ arch/riscv/include/asm/cpuidle.h | 11 +--- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/include/asm/processor.h | 31 +++++++++ arch/riscv/include/asm/smp.h | 14 ++++ arch/riscv/kernel/cpu.c | 5 ++ arch/riscv/kernel/cpufeature.c | 1 + arch/riscv/kernel/process.c | 102 ++++++++++++++++++++++++++++- arch/riscv/kernel/smp.c | 39 +++++++---- 9 files changed, 205 insertions(+), 23 deletions(-) -- 2.20.1
On Thu, Apr 18, 2024 at 1:50 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > This patch series introduces a new implementation of idle thread using > Zawrs extension. This overlaps with the following series: https://lore.kernel.org/all/20240315134009.580167-7-ajones@ventanamicro.com/ BR Christoph > > The Zawrs[0] extension introduces two new instructions named WRS.STO and > WRS.NTO in RISC-V. When software registers a reservation set using LR > instruction, a subsequent WRS.STO or WRS.NTO instruction will cause the > hart to stall in a low-power state until a store happens to the > reservation set or an interrupt becomes pending. The difference between > these two instructions is that WRS.STO will terminate stall after an > implementation-defined timeout while WRS.NTO won't. > > This patch series implements idle thread using WRS.NTO instruction. > Besides, we found there is no need to send a real IPI to wake up an idle > CPU. Instead, we write IPI information to the reservation set of an idle > CPU to wake it up and let it handle IPI quickly, without going through > tranditional interrupt handling routine. > > [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc > > Xu Lu (2): > riscv: process: Introduce idle thread using Zawrs extension > riscv: Use Zawrs to accelerate IPI to idle cpu > > arch/riscv/Kconfig | 24 +++++++ > arch/riscv/include/asm/cpuidle.h | 11 +--- > arch/riscv/include/asm/hwcap.h | 1 + > arch/riscv/include/asm/processor.h | 31 +++++++++ > arch/riscv/include/asm/smp.h | 14 ++++ > arch/riscv/kernel/cpu.c | 5 ++ > arch/riscv/kernel/cpufeature.c | 1 + > arch/riscv/kernel/process.c | 102 ++++++++++++++++++++++++++++- > arch/riscv/kernel/smp.c | 39 +++++++---- > 9 files changed, 205 insertions(+), 23 deletions(-) > > -- > 2.20.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Apr 18, 2024 at 8:26 PM Christoph Müllner <christoph.muellner@vrull.eu> wrote: > > On Thu, Apr 18, 2024 at 1:50 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > This patch series introduces a new implementation of idle thread using > > Zawrs extension. > > This overlaps with the following series: > https://lore.kernel.org/all/20240315134009.580167-7-ajones@ventanamicro.com/ Hi Christoph. Thanks for your reply! Actually our patch series is different from this. The work from your link focuses on providing support for Zawrs and implementing spinlock using it, while our work focuses on implementing idle thread using Zawrs and accelerating IPI to idle cpu. Of course, the ISA ZAWRS config part can be merged. We will refine our code in the next version to reduce code conflicts. > > BR > Christoph > > > > > The Zawrs[0] extension introduces two new instructions named WRS.STO and > > WRS.NTO in RISC-V. When software registers a reservation set using LR > > instruction, a subsequent WRS.STO or WRS.NTO instruction will cause the > > hart to stall in a low-power state until a store happens to the > > reservation set or an interrupt becomes pending. The difference between > > these two instructions is that WRS.STO will terminate stall after an > > implementation-defined timeout while WRS.NTO won't. > > > > This patch series implements idle thread using WRS.NTO instruction. > > Besides, we found there is no need to send a real IPI to wake up an idle > > CPU. Instead, we write IPI information to the reservation set of an idle > > CPU to wake it up and let it handle IPI quickly, without going through > > tranditional interrupt handling routine. > > > > [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc > > > > Xu Lu (2): > > riscv: process: Introduce idle thread using Zawrs extension > > riscv: Use Zawrs to accelerate IPI to idle cpu > > > > arch/riscv/Kconfig | 24 +++++++ > > arch/riscv/include/asm/cpuidle.h | 11 +--- > > arch/riscv/include/asm/hwcap.h | 1 + > > arch/riscv/include/asm/processor.h | 31 +++++++++ > > arch/riscv/include/asm/smp.h | 14 ++++ > > arch/riscv/kernel/cpu.c | 5 ++ > > arch/riscv/kernel/cpufeature.c | 1 + > > arch/riscv/kernel/process.c | 102 ++++++++++++++++++++++++++++- > > arch/riscv/kernel/smp.c | 39 +++++++---- > > 9 files changed, 205 insertions(+), 23 deletions(-) > > > > -- > > 2.20.1 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Apr 18, 2024 at 2:44 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > On Thu, Apr 18, 2024 at 8:26 PM Christoph Müllner > <christoph.muellner@vrull.eu> wrote: > > > > On Thu, Apr 18, 2024 at 1:50 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > > > This patch series introduces a new implementation of idle thread using > > > Zawrs extension. > > > > This overlaps with the following series: > > https://lore.kernel.org/all/20240315134009.580167-7-ajones@ventanamicro.com/ > > Hi Christoph. > Thanks for your reply! > Actually our patch series is different from this. The work from your > link focuses on providing support for Zawrs and implementing spinlock > using it, while our work focuses on implementing idle thread using > Zawrs and accelerating IPI to idle cpu. Of course, the ISA ZAWRS > config part can be merged. We will refine our code in the next version > to reduce code conflicts. Yes, I've seen that this targets another optimization, but the basic Zawrs support would be identical to the other patchset (even if it is not). I would propose that we work on a basic Zawrs support patchset that introduces the Kconfig, DTS and hwprobe parts (a subset of Andrew's patchset). Once this is merged, all other optimizations can be built upon it (spinlocks, idle thread, glibc CPU spinning). If this proposal is fine for the maintainers/reviewers, then Andrew could resend these basic-support patches. BR Christoph > > > > > BR > > Christoph > > > > > > > > The Zawrs[0] extension introduces two new instructions named WRS.STO and > > > WRS.NTO in RISC-V. When software registers a reservation set using LR > > > instruction, a subsequent WRS.STO or WRS.NTO instruction will cause the > > > hart to stall in a low-power state until a store happens to the > > > reservation set or an interrupt becomes pending. The difference between > > > these two instructions is that WRS.STO will terminate stall after an > > > implementation-defined timeout while WRS.NTO won't. > > > > > > This patch series implements idle thread using WRS.NTO instruction. > > > Besides, we found there is no need to send a real IPI to wake up an idle > > > CPU. Instead, we write IPI information to the reservation set of an idle > > > CPU to wake it up and let it handle IPI quickly, without going through > > > tranditional interrupt handling routine. > > > > > > [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc > > > > > > Xu Lu (2): > > > riscv: process: Introduce idle thread using Zawrs extension > > > riscv: Use Zawrs to accelerate IPI to idle cpu > > > > > > arch/riscv/Kconfig | 24 +++++++ > > > arch/riscv/include/asm/cpuidle.h | 11 +--- > > > arch/riscv/include/asm/hwcap.h | 1 + > > > arch/riscv/include/asm/processor.h | 31 +++++++++ > > > arch/riscv/include/asm/smp.h | 14 ++++ > > > arch/riscv/kernel/cpu.c | 5 ++ > > > arch/riscv/kernel/cpufeature.c | 1 + > > > arch/riscv/kernel/process.c | 102 ++++++++++++++++++++++++++++- > > > arch/riscv/kernel/smp.c | 39 +++++++---- > > > 9 files changed, 205 insertions(+), 23 deletions(-) > > > > > > -- > > > 2.20.1 > > > > > > > > > _______________________________________________ > > > linux-riscv mailing list > > > linux-riscv@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Apr 18, 2024 at 8:56 PM Christoph Müllner <christoph.muellner@vrull.eu> wrote: > > On Thu, Apr 18, 2024 at 2:44 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > On Thu, Apr 18, 2024 at 8:26 PM Christoph Müllner > > <christoph.muellner@vrull.eu> wrote: > > > > > > On Thu, Apr 18, 2024 at 1:50 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > > > > > This patch series introduces a new implementation of idle thread using > > > > Zawrs extension. > > > > > > This overlaps with the following series: > > > https://lore.kernel.org/all/20240315134009.580167-7-ajones@ventanamicro.com/ > > > > Hi Christoph. > > Thanks for your reply! > > Actually our patch series is different from this. The work from your > > link focuses on providing support for Zawrs and implementing spinlock > > using it, while our work focuses on implementing idle thread using > > Zawrs and accelerating IPI to idle cpu. Of course, the ISA ZAWRS > > config part can be merged. We will refine our code in the next version > > to reduce code conflicts. > > Yes, I've seen that this targets another optimization, but the basic > Zawrs support > would be identical to the other patchset (even if it is not). > I would propose that we work on a basic Zawrs support patchset that introduces > the Kconfig, DTS and hwprobe parts (a subset of Andrew's patchset). > Once this is merged, all other optimizations can be built upon it > (spinlocks, idle thread, glibc CPU spinning). > If this proposal is fine for the maintainers/reviewers, then Andrew could resend > these basic-support patches. > > BR > Christoph Roger that! This does make more sense. We will rebase our code on Andrew's basic support patches in the next version. Regards, Xu Lu > > > > > > > > > > BR > > > Christoph > > > > > > > > > > > The Zawrs[0] extension introduces two new instructions named WRS.STO and > > > > WRS.NTO in RISC-V. When software registers a reservation set using LR > > > > instruction, a subsequent WRS.STO or WRS.NTO instruction will cause the > > > > hart to stall in a low-power state until a store happens to the > > > > reservation set or an interrupt becomes pending. The difference between > > > > these two instructions is that WRS.STO will terminate stall after an > > > > implementation-defined timeout while WRS.NTO won't. > > > > > > > > This patch series implements idle thread using WRS.NTO instruction. > > > > Besides, we found there is no need to send a real IPI to wake up an idle > > > > CPU. Instead, we write IPI information to the reservation set of an idle > > > > CPU to wake it up and let it handle IPI quickly, without going through > > > > tranditional interrupt handling routine. > > > > > > > > [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc > > > > > > > > Xu Lu (2): > > > > riscv: process: Introduce idle thread using Zawrs extension > > > > riscv: Use Zawrs to accelerate IPI to idle cpu > > > > > > > > arch/riscv/Kconfig | 24 +++++++ > > > > arch/riscv/include/asm/cpuidle.h | 11 +--- > > > > arch/riscv/include/asm/hwcap.h | 1 + > > > > arch/riscv/include/asm/processor.h | 31 +++++++++ > > > > arch/riscv/include/asm/smp.h | 14 ++++ > > > > arch/riscv/kernel/cpu.c | 5 ++ > > > > arch/riscv/kernel/cpufeature.c | 1 + > > > > arch/riscv/kernel/process.c | 102 ++++++++++++++++++++++++++++- > > > > arch/riscv/kernel/smp.c | 39 +++++++---- > > > > 9 files changed, 205 insertions(+), 23 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > > > > > > > > > > _______________________________________________ > > > > linux-riscv mailing list > > > > linux-riscv@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Apr 18, 2024 at 09:09:06PM +0800, Xu Lu wrote: > On Thu, Apr 18, 2024 at 8:56 PM Christoph Müllner > <christoph.muellner@vrull.eu> wrote: > > > > On Thu, Apr 18, 2024 at 2:44 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > > > On Thu, Apr 18, 2024 at 8:26 PM Christoph Müllner > > > <christoph.muellner@vrull.eu> wrote: > > > > > > > > On Thu, Apr 18, 2024 at 1:50 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > > > > > > > This patch series introduces a new implementation of idle thread using > > > > > Zawrs extension. > > > > > > > > This overlaps with the following series: > > > > https://lore.kernel.org/all/20240315134009.580167-7-ajones@ventanamicro.com/ > > > > > > Hi Christoph. > > > Thanks for your reply! > > > Actually our patch series is different from this. The work from your > > > link focuses on providing support for Zawrs and implementing spinlock > > > using it, while our work focuses on implementing idle thread using > > > Zawrs and accelerating IPI to idle cpu. Of course, the ISA ZAWRS > > > config part can be merged. We will refine our code in the next version > > > to reduce code conflicts. > > > > Yes, I've seen that this targets another optimization, but the basic > > Zawrs support > > would be identical to the other patchset (even if it is not). > > I would propose that we work on a basic Zawrs support patchset that introduces > > the Kconfig, DTS and hwprobe parts (a subset of Andrew's patchset). > > Once this is merged, all other optimizations can be built upon it > > (spinlocks, idle thread, glibc CPU spinning). > > If this proposal is fine for the maintainers/reviewers, then Andrew could resend > > these basic-support patches. > > > > BR > > Christoph > > Roger that! This does make more sense. We will rebase our code on > Andrew's basic support patches in the next version. And I'm just about to send that next version. I'll send tomorrow morning if not yet today. Thanks, drew > > Regards, > Xu Lu > > > > > > > > > > > > > > > > BR > > > > Christoph > > > > > > > > > > > > > > The Zawrs[0] extension introduces two new instructions named WRS.STO and > > > > > WRS.NTO in RISC-V. When software registers a reservation set using LR > > > > > instruction, a subsequent WRS.STO or WRS.NTO instruction will cause the > > > > > hart to stall in a low-power state until a store happens to the > > > > > reservation set or an interrupt becomes pending. The difference between > > > > > these two instructions is that WRS.STO will terminate stall after an > > > > > implementation-defined timeout while WRS.NTO won't. > > > > > > > > > > This patch series implements idle thread using WRS.NTO instruction. > > > > > Besides, we found there is no need to send a real IPI to wake up an idle > > > > > CPU. Instead, we write IPI information to the reservation set of an idle > > > > > CPU to wake it up and let it handle IPI quickly, without going through > > > > > tranditional interrupt handling routine. > > > > > > > > > > [0] https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc > > > > > > > > > > Xu Lu (2): > > > > > riscv: process: Introduce idle thread using Zawrs extension > > > > > riscv: Use Zawrs to accelerate IPI to idle cpu > > > > > > > > > > arch/riscv/Kconfig | 24 +++++++ > > > > > arch/riscv/include/asm/cpuidle.h | 11 +--- > > > > > arch/riscv/include/asm/hwcap.h | 1 + > > > > > arch/riscv/include/asm/processor.h | 31 +++++++++ > > > > > arch/riscv/include/asm/smp.h | 14 ++++ > > > > > arch/riscv/kernel/cpu.c | 5 ++ > > > > > arch/riscv/kernel/cpufeature.c | 1 + > > > > > arch/riscv/kernel/process.c | 102 ++++++++++++++++++++++++++++- > > > > > arch/riscv/kernel/smp.c | 39 +++++++---- > > > > > 9 files changed, 205 insertions(+), 23 deletions(-) > > > > > > > > > > -- > > > > > 2.20.1 > > > > > > > > > > > > > > > _______________________________________________ > > > > > linux-riscv mailing list > > > > > linux-riscv@lists.infradead.org > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Apr 18, 2024 at 09:09:06PM +0800, Xu Lu wrote: > On Thu, Apr 18, 2024 at 8:56 PM Christoph Müllner > <christoph.muellner@vrull.eu> wrote: > > > > On Thu, Apr 18, 2024 at 2:44 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > > > On Thu, Apr 18, 2024 at 8:26 PM Christoph Müllner > > > <christoph.muellner@vrull.eu> wrote: > > > > > > > > On Thu, Apr 18, 2024 at 1:50 PM Xu Lu <luxu.kernel@bytedance.com> wrote: > > > > > > > > > > This patch series introduces a new implementation of idle thread using > > > > > Zawrs extension. > > > > > > > > This overlaps with the following series: > > > > https://lore.kernel.org/all/20240315134009.580167-7-ajones@ventanamicro.com/ > > > > > > Hi Christoph. > > > Thanks for your reply! > > > Actually our patch series is different from this. The work from your > > > link focuses on providing support for Zawrs and implementing spinlock > > > using it, while our work focuses on implementing idle thread using > > > Zawrs and accelerating IPI to idle cpu. Of course, the ISA ZAWRS > > > config part can be merged. We will refine our code in the next version > > > to reduce code conflicts. > > > > Yes, I've seen that this targets another optimization, but the basic > > Zawrs support > > would be identical to the other patchset (even if it is not). > > I would propose that we work on a basic Zawrs support patchset that introduces > > the Kconfig, DTS and hwprobe parts (a subset of Andrew's patchset). > > Once this is merged, all other optimizations can be built upon it > > (spinlocks, idle thread, glibc CPU spinning). > > If this proposal is fine for the maintainers/reviewers, then Andrew could resend > > these basic-support patches. > > > > BR > > Christoph > > Roger that! This does make more sense. We will rebase our code on > Andrew's basic support patches in the next version. IIRC Drew's working on a new version of the linked series (we were talking about it yesterday) so hold off for that before doing a rebase and sending a new version I think. Thanks, Conor.
© 2016 - 2024 Red Hat, Inc.