linux-kernel - Re: [PATCH v2] LoongArch: add checksum optimization for 64-bit system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ff1ede2c-8289-a833-3997-48f8a30dc606@loongson.cn>
Date:   Thu, 16 Feb 2023 17:26:13 +0800
From:   maobibo <maobibo@...ngson.cn>
To:     David Laight <David.Laight@...LAB.COM>,
        Huacai Chen <chenhuacai@...nel.org>
Cc:     WANG Xuerui <kernel@...0n.name>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] LoongArch: add checksum optimization for 64-bit system



在 2023/2/16 17:03, David Laight 写道:
> From: maobibo
>> Sent: 14 February 2023 14:19
> ...
>> Got it. It makes use of pipeline better, rather than number of ALUs for
>> different micro-architectures. I will try this method, thanks again for
>> kindly help and explanation with patience.
> 
> It is also worth pointing out that if the cpu does 'out of order'
> execution it may be just as good to just repeat blocks of:
> 	load	v0, addr, 0*8
> 	add	sum0, v0
> 	sltu	v0, sum0, v0
> 	add	carry0, v0
> 
It is strange that there is no performance improvement on my loongarch
machine when interleaving ALU instructions before load; however on x86
box the performance improvement is huge compared to uint128 function.

Here is the piece of of the code:
        while (len > 48) {
                len -= 48;
                tmp4 = *(unsigned long *)ptr;
                if (tmp1 < tmp2)
                        tmp1 += 1;
                tmp3 += tmp4;

                tmp0 = *(unsigned long *)(ptr + 1);
                if (tmp3 < tmp4)
                        tmp3 += 1;
                sum64 += tmp0;

                tmp2 = *(unsigned long *)(ptr + 2);
                if (sum64 < tmp0)
                        sum64 += 1;
                tmp1 += tmp2;

                tmp4 = *(unsigned long *)(ptr + 3);
                if (tmp1 < tmp2)
                        tmp1 +=1;
                tmp3 += tmp4;

                tmp0 = *(unsigned long *)(ptr + 4);
                if (tmp3 < tmp4)
                        tmp3 +=1;
                sum64 += tmp0;

                tmp2 = *(unsigned long *)(ptr + 5);
                if (sum64 < tmp0)
                        sum64 += 1;
                tmp1 += tmp2;
                ptr += 6;
        }

Regards
Bibo, Mao
> Assuming the prefetch/decode logic can predict the loop
> and generate enough decoded instruction for all the alu units.
> 
> The add/sltu/add will be queued until the load completes
> and then execute in the next three clocks.
> The load for the next block will be scheduled as soon as
> the load/store unit has finished processing the previous load.
> So all the alu instructions just wait for the required input
> to be available and a memory load executes every clock.
> 
> Multiple sum0 and carry0 registers aren't actually needed.
> But having 2 of each (even if the loop is unrolled 4 times)
> might help a bit.
> 
> If the cpu does 'register renaming' (as most x86 do) you
> can use the same register name for 'v0' in all the blocks
> (even though it is alive with multiple values).
> 
> But a simpler in-order multi-issue cpu will need you to
> correctly interleave the instructions for maximum throughput.
> It also does no hard for a very simple cpu that has delays
> before a read value can be used.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)