From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C8705C46CD2 for ; Wed, 24 Jan 2024 17:55:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rgPyeysXzpuT7Y0+GPaBnBMfLTaDT3PJGp+TV5CrUQc=; b=sIABchcYwliR/L HagEA74X+NXCkPcUQgcfRBeWkWycWmu71GpFfS6B7UNW1Ua3OEo+fTaHyCQWZ+V1uwBPsk+9q/sbl VeNvT1ZlzpBCth9xugMYFC67c1JKtt1s4zeRYzlwCY1GmQqwkBblzg2OpRQLOj4NyZzeIRKXY89fe HHMRJWBVjm//QpjE+PKndvKS83NE0ChgnWaPR0ILDvvi/TmZeO4+2jnpvJLJ4QSbQ5rvwbRznhyaO TlQ+EmM7Vn7NrFGOFZx/yxn6/YQfGT48TMUQrHNm4qSTn8TQtGJdTWjm+pjhfG9NwjCRi5N12Nr4o Vt7bVzxxWB9T16WNgmvQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rShSn-004bGZ-0A; Wed, 24 Jan 2024 17:55:01 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rShSj-004bER-1A for linux-arm-kernel@lists.infradead.org; Wed, 24 Jan 2024 17:54:59 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 6B05ECE31A5; Wed, 24 Jan 2024 17:54:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D0D4C433F1; Wed, 24 Jan 2024 17:54:51 +0000 (UTC) Date: Wed, 24 Jan 2024 17:54:49 +0000 From: Catalin Marinas To: Jason Gunthorpe Cc: Marc Zyngier , Mark Rutland , Niklas Schnelle , Leon Romanovsky , Arnd Bergmann , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rdma@vger.kernel.org, llvm@lists.linux.dev, Michael Guralnik , Nathan Chancellor , Nick Desaulniers , Will Deacon Subject: Re: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64 Message-ID: References: <20240116185121.GB980613@nvidia.com> <20240117123618.GD734935@nvidia.com> <20240124012723.GD1455070@nvidia.com> <86ede787d7.wl-maz@kernel.org> <20240124130638.GE1455070@nvidia.com> <86bk9a97rt.wl-maz@kernel.org> <20240124155225.GG1455070@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240124155225.GG1455070@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240124_095457_595261_B487E5DE X-CRM114-Status: GOOD ( 20.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 24, 2024 at 11:52:25AM -0400, Jason Gunthorpe wrote: > On Wed, Jan 24, 2024 at 01:32:22PM +0000, Marc Zyngier wrote: > > What I'm saying is that there are way to make it better without > > breaking your particular toy workload which, as important as it may be > > to *you*, doesn't cover everybody's use case. > > Please, do we need the "toy" stuff? The industry is spending 10's of > billions of dollars right now to run "my workload". Currently not > widely on ARM servers, but we are all hoping ARM can succeed here, > right? > > I still don't know what you mean by "better". There are several issues > now > > 1) This series, where WC doesn't trigger on new cores. Maybe 8x STR > will fix it, but it is not better performance wise than 4x STP. It would be good to know. If the performance difference is significant, we can revisit. I'm not keen on using alternatives here without backing it up by numbers (do we even have a way to detect whether Linux is running natively or not? we may have to invent something). > 2) Userspace does ST4 to MMIO memory, and the VMM can't explode > because of this. Replacing the ST4 with 8x STR is NOT better, > that would be a big performance downside, especially for the > quirky hi-silicon hardware. I was hoping KVM injects an error into the guest rather than killing it but at a quick look I couldn't find it. The kvm_handle_guest_abort() -> io_mem_abort() ends up returning -ENOSYS while handle_trap_exceptions() only understands handled or not (like 1 or 0). Well, maybe I didn't look deep enough. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel