Message ID | 20231229143627.22898-1-andy.chiu@sifive.com (mailing list archive) |
---|---|
Headers | show |
Series | riscv: support kernel-mode Vector | expand |
Hi Palmer,
On Fri, Dec 29, 2023 at 02:36:17PM +0000, Andy Chiu wrote:
> This series provides support running Vector in kernel mode.
Is there any chance that you can take patches 1 and 2 of this series via the
RISC-V tree for v6.8? The vector crypto patchset depends on those two patches.
Thanks,
- Eric
On Sat, Jan 6, 2024 at 2:59 AM Eric Biggers <ebiggers@kernel.org> wrote: > > Hi Palmer, > > On Fri, Dec 29, 2023 at 02:36:17PM +0000, Andy Chiu wrote: > > This series provides support running Vector in kernel mode. > > Is there any chance that you can take patches 1 and 2 of this series via the > RISC-V tree for v6.8? The vector crypto patchset depends on those two patches. Patch 4 is very essential for non-preemptible kernel-mode Vector, unless we want to bear restoring overhead at each kernel_vector_end(). It's ~200 cycles on a VLEN=128 hardware. It happens as long as Vector is also used in user-mode, which will be very common. Please consider including up to patch 4 if we must split. > > Thanks, > > - Eric Thanks, Andy
On Mon, Jan 08, 2024 at 11:16:27AM +0800, Andy Chiu wrote: > On Sat, Jan 6, 2024 at 2:59 AM Eric Biggers <ebiggers@kernel.org> wrote: > > > > Hi Palmer, > > > > On Fri, Dec 29, 2023 at 02:36:17PM +0000, Andy Chiu wrote: > > > This series provides support running Vector in kernel mode. > > > > Is there any chance that you can take patches 1 and 2 of this series via the > > RISC-V tree for v6.8? The vector crypto patchset depends on those two patches. > > Patch 4 is very essential for non-preemptible kernel-mode Vector, > unless we want to bear restoring overhead at each kernel_vector_end(). > It's ~200 cycles on a VLEN=128 hardware. It happens as long as Vector > is also used in user-mode, which will be very common. Please consider > including up to patch 4 if we must split. > It's definitely an important optimization, but I wouldn't call it "very essential". x86 didn't implement lazy restores until kernel v5.2. My hope is that we can just get enough merged soon to unblock the vector crypto patchset, which just needs kernel_vector_{begin,end} with softirq support. The remaining core vector work can happen in parallel. - Eric
On Sun, 07 Jan 2024 19:52:09 PST (-0800), ebiggers@kernel.org wrote: > On Mon, Jan 08, 2024 at 11:16:27AM +0800, Andy Chiu wrote: >> On Sat, Jan 6, 2024 at 2:59 AM Eric Biggers <ebiggers@kernel.org> wrote: >> > >> > Hi Palmer, >> > >> > On Fri, Dec 29, 2023 at 02:36:17PM +0000, Andy Chiu wrote: >> > > This series provides support running Vector in kernel mode. >> > >> > Is there any chance that you can take patches 1 and 2 of this series via the >> > RISC-V tree for v6.8? The vector crypto patchset depends on those two patches. >> >> Patch 4 is very essential for non-preemptible kernel-mode Vector, >> unless we want to bear restoring overhead at each kernel_vector_end(). >> It's ~200 cycles on a VLEN=128 hardware. It happens as long as Vector >> is also used in user-mode, which will be very common. Please consider >> including up to patch 4 if we must split. >> > > It's definitely an important optimization, but I wouldn't call it "very > essential". x86 didn't implement lazy restores until kernel v5.2. > > My hope is that we can just get enough merged soon to unblock the vector crypto > patchset, which just needs kernel_vector_{begin,end} with softirq support. The > remaining core vector work can happen in parallel. Andy says he's going to send a v10 tomorrow, I'll plan on merging that. > > - Eric > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv