Received-SPF: pass (google.com: domain of linux-kernel+bounces-18754-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Sat, 06 Jan 2024 17:09:09 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
To: David Laight <David.Laight@ACULAB.COM>,
        "'Linus Torvalds'" <torvalds@linux-foundation.org>
CC: Noah Goldstein <goldstein.w.n@gmail.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "oe-kbuild-all@lists.linux.dev" <oe-kbuild-all@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "edumazet@google.com" <edumazet@google.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: RE: x86/csum: Remove unnecessary odd handling
User-Agent: K-9 Mail for Android
In-Reply-To: <124b21857fe44e499e29800cbf4f63f8@AcuMS.aculab.com>
References: <20230920192300.3772199-1-goldstein.w.n@gmail.com> <202309231130.ZI5MdlDc-lkp@intel.com> <CAFUsyfKDRiX9kKOhHcA4PLqqT6Q5faHF0eRGiKN+9NSbvrUfDw@mail.gmail.com> <d02bd4f823534a00ae4915ead3d92773@AcuMS.aculab.com> <CAFUsyfL0M5P4+4s_b1kvJ_fE-ax8YBK0ammbKfoy7yKs1obzrA@mail.gmail.com> <CAFUsyfJduB29c6=BNmTtgoWcHAWA1AZ-sdbhyp02JVhvA6Gp0w@mail.gmail.com> <CAFUsyfLuo0_Sm91mqbM8Sbo-ncwnM4RaRq=GxQXDmkAN-nQ3uw@mail.gmail.com> <CAHk-=wgv6h4ru=z8UR5XyutoRKveOetNpwovHburvRgG9NSa3g@mail.gmail.com> <CAHk-=wiNUucmvTKGmveWzXXe99SpOwU65nFtH-A2_aUpPsAPJQ@mail.gmail.com> <5354eeec562345f6a1de84f0b2081b75@AcuMS.aculab.com> <CAHk-=wg8vssPVO68_qH_BHBCj6_DDawKQHBOgZh4gw5YFmpCKA@mail.gmail.com> <124b21857fe44e499e29800cbf4f63f8@AcuMS.aculab.com>
Message-ID: <4313F9BB-DE2E-448F-A366-A68CAEA2BFE0@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On January 6, 2024 2:08:48 PM PST, David Laight <David=2ELaight@ACULAB=2ECO=
M> wrote:
>From: Linus Torvalds
>> Sent: 05 January 2024 18:06
>>=20
>> On Fri, 5 Jan 2024 at 02:41, David Laight <David=2ELaight@aculab=2Ecom>=
 wrote:
>> >
>> > Interesting, I'm pretty sure trying to get two blocks of
>> >  'adc' scheduled in parallel like that doesn't work=2E
>>=20
>> You should check out the benchmark at
>>=20
>>        https://github=2Ecom/fenrus75/csum_partial
>>=20
>> and see if you can improve on it=2E I'm including the patch (on top of
>> that code by Arjan) to implement the actual current kernel version as
>> "New version"=2E
>
>Annoyingly (for me) you are partially right=2E=2E=2E
>
>I found where my ip checksum perf code was hiding and revisited it=2E
>Although I found comments elsewhere that the 'jecxz, adc, adc, lea, jmp'
>did an adc every clock it isn't happening for me now=2E
>
>I'm only measuring the inner loop for multiples of 64 bytes=2E
>The code less than 8 bytes and partial final words is a
>separate problem=2E
>The less unrolled the main loop, the less overhead there'll
>be for 'normal' sizes=2E
>So I've changed your '80 byte' block to 64 bytes for consistency=2E
>
>I'm ignoring pre-sandy bridge cpu (no split flags) and pre-broadwell
>(adc takes two clocks - although adc to alternate regs is one clock
>on sandy bridge)=2E
>My test system is an i7-7700, I think anything from broadwell (gen 4)
>will be at least as good=2E
>I don't have a modern amd cpu=2E
>
>The best loop for 256+ bytes is an adxc/adxo one=2E
>However that requires the run-time patching=2E
>Followed by new kernel version (two blocks of 4 adc)=2E
>The surprising one is:
>		xor	sum, sum
>	1:	adc	(buff), sum
>		adc	8(buff), sum
>		lea	16(buff), buff
>		dec	count
>		jnz	1b
>		adc	$0, sum
>For 256 bytes it is only a couple of clocks slower=2E
>Maybe 10% slower for 512+ bytes=2E
>But it need almost no extra code for 'normal' buffer sizes=2E
>By comparison the adxc/adxo one is 20% faster=2E
>
>The code is doing:
>	old =3D rdpmc
>	mfence
>	csum =3D do_csum(buf, len);
>	mfence
>	clocks =3D rdpmc - old
>(That is directly reading the pmc register=2E)
>With 'no-op' function it takes 160 clocks (I-cache resident)=2E
>Without the mfence 40 - but pretty much everything can execute
>after the 2nd rdpmc=2E
>
>I've attached my (horrid) test program=2E
>
>	David
>
>-
>Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1=
 1PT, UK
>Registration No: 1397386 (Wales)

Rather than runtime patching perhaps separate paths=2E=2E=2E