linux-kernel - Re: [PATCH] lib/bch.c: increase bitrev single conversion length

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: <CAHk-=wgxkAgRPb7ZZ+w7UHhp2OuV=pc_C7D+hEYcA65ieMFt0g@mail.gmail.com>
Date: Sun, 4 Feb 2024 09:09:16 +0000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: John Sanpe <sanpeqf@...il.com>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org, rdunlap@...radead.org, 
	unixbhaskar@...il.com, mm-commits@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lib/bch.c: increase bitrev single conversion length

On Sun, 4 Feb 2024 at 08:52, John Sanpe <sanpeqf@...il.com> wrote:
>
> Optimized the performance of the three functions (load_ecc8 store_ecc8
> and bch_encode) using a larger calculation length.

Honestly, with any optimization, you should quote performance numbers.

Also, it's questionable how meaningful this is, considering that most
architectures dop the bit swap with a byte lookup, and the 32-bit bit
swap is just four byte lookups. For all we know, this only makes
things worse.

Finally, if you actually want to do things in bigger chunks, that
->swap_bits conditional should probably be moved out of the loops, not
just have that questionable 8->32 bit expansion.

            Linus