From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a3-smtp.messagingengine.com (fhigh-a3-smtp.messagingengine.com [103.168.172.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD5BE3B192 for ; Mon, 27 Jan 2025 15:48:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.154 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737992924; cv=none; b=YFoXi39vRSxbQdaqYbT2II+IFIXaaK2Xvz6nswzrEvftH6cQxTVWW0m88V2G7AcDhjSFrlCEWCrCcVmYakYbJvQIPUvQfcyLNJ8Ct82hlD9m4CDBx+a17VeGJ00MKJWNRVqqg48TeCWQHR9XAaWsg52ebBBdI+BgVSNRHgswMNo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737992924; c=relaxed/simple; bh=r8R5O6IRW4DQuaIpaNDeC0XY5Q1/+jwWwpI0dn20gb4=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=YN8VfaGIny2RrwZ2uev+Q3WIAqIKADFiXezCzL84XKTuhttz9l4wTsKRt/htaDbCag9GNZ7RNtxQWlSpS3wBTCGfT1qeokU/+JW2X9BtR4/H/QDkznhb9Nlet/yrBjEjwzii/4+hrKESKg0Kgv9HxFl+5AV8adF2Csl8SnzO5jM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=c65rwuv9; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=qTXCO2T4; arc=none smtp.client-ip=103.168.172.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="c65rwuv9"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="qTXCO2T4" Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 6CFAD1140272; Mon, 27 Jan 2025 10:48:40 -0500 (EST) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-10.internal (MEProxy); Mon, 27 Jan 2025 10:48:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1737992920; x=1738079320; bh=9sGlifjkTv3apdybJpheayb6Fn6r0GovDXKQUCGkRDE=; b= c65rwuv9uk5p1POTPzT4/S9vnGD+HjdsOJhwhSQ9ToCTcd7GpnCoM9jBoxWLi8/F GL5ZN2RpP0wbhDF8fSdw97Rh7m7IVyn9Kp8q+kS1KS0wssWP9TxZ2ke0u8ugI9jK DHKjaqcnMafpDYunE3H9Ec7OhSpgBqTFYYMkSI7kV+VZOeDIopoOsz8ZYH1aNW8T u/JMMJw76utWrW1VELzjNM+1ih0NnH70U+wcLrkXYJwxDvFw6QY9fJD3uLn7EsBT 65jS69xlt2LuEXVGflcAEUzArK1Zw40sqnOjYeDGHHv75MtJKitrR/p+FSEfwhS4 6tPioT7g3NBdIZqBIqziDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1737992920; x= 1738079320; bh=9sGlifjkTv3apdybJpheayb6Fn6r0GovDXKQUCGkRDE=; b=q TXCO2T4W8dB8vaZwGproy80X5Tp3IZ1XbAEfF4jqd/aQZppNaawUr+v8cG0gJcga 9hRfpmEuQOrB/0Ln6FH5ymwItGrm9jRU20wIhECTx5w6FgQHTye67dWsEmXTqBKj szc0E6UxgrzHOEC7GMngI7xOKGki+V/7DCOJGx+cDiko7Hk7kC2XuwxyE1zwM6Ox WVZDmORQRkKYU5crPwFM4w7DRGYq01L8CuJ0dbMuO9AU+1C60YBs+gOajAM/p232 GjZXniEJDXoaikVtYR6HkPgG6QSwfLkNb+F/GnQZD+raQvHXBLpqIEdMtpmZqvbm A69Y/fqBvM50QEqELYpAQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgudefheekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtjeertder tddtnecuhfhrohhmpedftehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnug gsrdguvgeqnecuggftrfgrthhtvghrnhephfdthfdvtdefhedukeetgefggffhjeeggeet fefggfevudegudevledvkefhvdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfoh hunhgurghtihhonhdrohhrghdprhgtphhtthhopehjuhhlihgrnhesohhuthgvrhdqlhhi mhhithhsrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkh gvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 040782220072; Mon, 27 Jan 2025 10:48:40 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Mon, 27 Jan 2025 16:48:18 +0100 From: "Arnd Bergmann" To: "Julian Vetter" , "Andrew Morton" Cc: linux-kernel@vger.kernel.org Message-Id: <308d30b7-acdb-43ec-bb27-7912a5351bcc@app.fastmail.com> In-Reply-To: References: <20250127100407.866238-1-julian@outer-limits.org> <1db6ef22-453e-4d31-a643-8e6f84a025e4@app.fastmail.com> Subject: Re: [PATCH] Add io_sync stubs to generic IO memcpy/memset Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Jan 27, 2025, at 15:11, Julian Vetter wrote: > On 1/27/25 11:27, Arnd Bergmann wrote: >> On Mon, Jan 27, 2025, at 11:04, Julian Vetter wrote: > > Thank you for your quick reply. You're right, I was just going with the > naming used in the powerpc arch which has an io_sync define. I'm now > wondering if we can't simply use the read{l,q}/write{l,q} functions > (instead of the __raw_xxx version), there are already calls to __io_br > before and__io_ar after each read (and write). But this might have > performance implications on some architectures, depending what it > resolves to. > > Otherwise I propose renaming the __pre_io_sync and __post_io_sync into a > single __io_mbr which is called before and after each loop. Looking at > PowerPC and SuperH, both of them could be consolidated into the generic > IO memcpy code when adding this. What do you think? Having barriers between the accesses would be very expensive, and prevent the write-combining and prefetching that can otherwise happen (depending on mapping flags). I suspect that the powerpc variant got this wrong for historic reasons, but that's hard to tell now. The ppc32 variant didn't have barriers at all originally, it was just memcpy/memset before it got combined with ppc64 into arch/powerpc. > The existing ones, especially __io_br unfortunately don't resolve to the > right define on these architectures. The __io_ar and __io_br resolve to > the right mb() on SuperH and PowerPC as well, but this would again have > implications on other architectures. The barriers in the sh functions seem arbitrary, and I would expect them to be wrong. ARnd