From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.219]) (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 404FAA59 for ; Tue, 28 Jan 2025 08:32:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=81.169.146.219 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738053181; cv=pass; b=T8/FOzil0O0FAFCbB4bHRWX2GyX07kKJ9+PU7Hg4Lv8KdX9YK77W+bYBByMNWpy7QYl3kCqB9LrF2dOr3w2z8t/u0UpGF8rebsGDzggun1mMabAI18kMPIcZPCo8VTjrASZHf7MM0YkWjSCqDr7LFx13MibI1BAc59vvt/p1A+8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738053181; c=relaxed/simple; bh=mXC2ar+buj/NHA4EMpvGDxJUeD4RcHofKdNp9NEe33Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=guZSzgMfLPq+++lBLcqE3HoBG3Q56JsVkddbhHEmVmgAS5drLX78DgOf1neP+PTM9MpSboa7wbHhugaGrmfoGIgLyvka5JH+wJADCXBuOK8t1LPrWy/HprwoaFDqfbgIzsYxYt5reNe5AohhJlxTKrAAzQho4GtRaPOdsaSAkmc= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=outer-limits.org; spf=none smtp.mailfrom=outer-limits.org; dkim=pass (2048-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b=XMU4PMC3; dkim=permerror (0-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b=bqHwGVBf; arc=pass smtp.client-ip=81.169.146.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=outer-limits.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=outer-limits.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b="XMU4PMC3"; dkim=permerror (0-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b="bqHwGVBf" ARC-Seal: i=1; a=rsa-sha256; t=1738053176; cv=none; d=strato.com; s=strato-dkim-0002; b=IxPwzwtLHlzFtCX9MbwAdOlJA06KNiQb/lfGYEJX9ODZgvBJeIbnPUONUi+oqPmVc9 iNHd8WhIsl7Vq3J0o6WIkRWKVpQIfVx/AlLx4IbA9p5zKOVwAw35aLzguy7XGJR4i7oW IYyb7lerotUfB2MUcOywFg/ruxcF8Go9ilPL54RkhGZMfaUgLX/U61GV3A4bw/pmYwfD bem3dkd6TAXYGmTakJrbyReA3b/DfWz9ANeyxuGjE7em2lQU7jkKUyZOS9kroc6kmVsJ zFqBawMwfU1i+Mlkys+Xd0jR2eNckkE7PQKeAIdRW5aGrAOUlh0NeEsmZrL53XDWczv3 h41g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1738053176; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=DT9KLNlAyHzxaMkxNCk97wtchdbZjmgMEp8uZHOj164=; b=RBPzgIYM1StHoQs7PAB6SUVKE5lMgBL3NYH+a3fKdFJtTaoTi1A3tdZ62iOU27Co98 yGapc3RlJj+Wxt3HSMC5AL3J/JjPpi/yjadEKuP61ZyYPXTnKc4sCCyzOoaP1NqbOHlS VHhZpivCWtgTlLCbbPUk3dgvec4FjUuNv/pux4hFMrhuMhWvhLcxHVgNE03kyYM8NEjm K6R8zWuIvxpOHN7krkNMCRpP/u+AK/jIS/xq5nnlxi8bfl5TKppYiI2zmeuQOPKciMYt rg9rTAV9zw6cQQ46zdunLyguUgCHoTNtxRr3AwDcos4++IHNKMfIpvJdU3mOrENDOwca eDUg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1738053176; s=strato-dkim-0002; d=outer-limits.org; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=DT9KLNlAyHzxaMkxNCk97wtchdbZjmgMEp8uZHOj164=; b=XMU4PMC386lc/RLXHk4j/o0u4+ZDu3CzEhqhqKZUK9NNJEGrWA8emJU3NZSnZRS0c1 Z7vk2Oz1fFD1Oef1dLtbWIem9CM/yNac3TE1PF68cgArfUk3EfA73K8/uUPd672tBScA EpEzvYUf3552AEUw+MoXlB9ZG7925Xt2GqbWY+2wxt7SQLQJpViYCU0I4ylDTAnB86g3 fJukJlK8C2uLMSriLlIEEX4/zNS7NVZLMK07LgIuWVKHuODU6MHWwVN8L/fKIkOh7BNa T3YdJew2VHY4+NaiWXLXVSKqpxMpd5o/9owx8VqdOX3pVdBXjCVfA/rQPISYT9cYZZFa TyRQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1738053176; s=strato-dkim-0003; d=outer-limits.org; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=DT9KLNlAyHzxaMkxNCk97wtchdbZjmgMEp8uZHOj164=; b=bqHwGVBfFm2ARcca7sTl4ycBImbiGSAcTcKyU6We1gHvRenWCB9b/1UjF4XHm/qPxr LjSqPaXEv2Ii0sH2usCA== X-RZG-AUTH: ":JnkIfEGmW/AMJS6HttH4FbRVwc4dHlPLCp4e/IoHo8zEMMHAgwTfqBEHcVJSv9P5mRTGd2ImeA==" Received: from [192.168.37.162] by smtp.strato.de (RZmta 51.2.17 AUTH) with ESMTPSA id J1a25110S8Wt0Dw (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 28 Jan 2025 09:32:55 +0100 (CET) Message-ID: <8f22066a-a2cc-4e6d-91aa-a2bdd0e53b79@outer-limits.org> Date: Tue, 28 Jan 2025 09:32:55 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add io_sync stubs to generic IO memcpy/memset To: Arnd Bergmann , Andrew Morton Cc: linux-kernel@vger.kernel.org References: <20250127100407.866238-1-julian@outer-limits.org> <1db6ef22-453e-4d31-a643-8e6f84a025e4@app.fastmail.com> <308d30b7-acdb-43ec-bb27-7912a5351bcc@app.fastmail.com> Content-Language: en-US From: Julian Vetter In-Reply-To: <308d30b7-acdb-43ec-bb27-7912a5351bcc@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/27/25 16:48, Arnd Bergmann wrote: > 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). Yes, ok. I see. > > 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. > hmmm... ok. I'm not sure what do make of this. But maybe I can just send a patch to the PowerPC mailinglist, without those "sync" calls and see what they have to say. >> 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. > Ok, same for SuperH, I will send a patch to the mailinglist without the 'mb()' before and after and see what they say. If they don't like it, I will come back to this. Julian > > ARnd