Re: [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
On 27 Mar 2023, at 13:13, Arnd Bergmann wrote: > > From: Arnd Bergmann > > No other architecture intentionally writes back dirty cache lines into > a buffer that a device has just finished writing into. If the cache is > clean, this has no effect at all, but if a cacheline in the buffer has > actually been written by the CPU, there is a drive bug that is likely > made worse by overwriting that buffer. FYI [1] proposed this same change a while ago but its justification was flawed (which was my objection at the time, not the diff itself). Jess [1] https://lore.kernel.org/all/20220818165105.99746-1-s.miroshniche...@yadro.com > Signed-off-by: Arnd Bergmann > --- > arch/riscv/mm/dma-noncoherent.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index d919efab6eba..640f4c496d26 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size, > break; > case DMA_FROM_DEVICE: > case DMA_BIDIRECTIONAL: > - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); > + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size); > break; > default: > break; > -- > 2.39.2 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
On 13 Jan 2023, at 21:03, Luck, Tony wrote: > >> For what it's worth, Debian and Gentoo both have ia64 ports with active >> users (6.1 looks like it currently fails to build in Debian due to a >> minor packaging issue, but various versions of 6.0 were built and >> published, and one of those is running on the one ia64 Debian builder I >> personally have access to). > > Jess, > > So dropping ia64 from the upstream kernel won't just save time of kernel > developers. It will also save time for the folks keeping Debian and Gentoo > ports up and running. > > Are there people actually running production systems on ia64 that also > update to v6.x kernels? > > If so, why? Just scrap the machine and replace with almost anything else. > You'll cover the cost of the new machine in short order with the savings on > your power bill. Hobbyists, same as alpha, hppa, m68k, sh and any other such architectures that have no real use in this day and age. Jess
Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)
On Fri, Jan 13, 2023 at 08:55:41AM +0100, Ard Biesheuvel wrote: > On Fri, 13 Jan 2023 at 01:31, Luck, Tony wrote: > > > > > Yeah, if it was ia64-only, it's a non-issue these days. It's dead and > > > in pure maintenance mode from a kernel perspective (if even that). > > > > There's not much "simultaneous" in the SMT on ia64. One thread in a > > spin loop will hog the core until the h/w switches to the other thread some > > number of cycles (hundreds, thousands? I really can remember). So I > > was pretty generous with dropping cpu_relax() into any kind of spin loop. > > > > Is it time yet for: > > > > $ git rm -r arch/ia64 > > > > Hi Tony, > > Can I take that as an ack on [0]? The EFI subsystem has evolved > substantially over the years, and there is really no way to do any > IA64 testing beyond build testing, so from that perspective, dropping > it entirely would be welcomed. For what it's worth, Debian and Gentoo both have ia64 ports with active users (6.1 looks like it currently fails to build in Debian due to a minor packaging issue, but various versions of 6.0 were built and published, and one of those is running on the one ia64 Debian builder I personally have access to). Jess
