From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 492DD280CFC; Sat, 28 Feb 2026 07:35:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772264157; cv=none; b=hK/Kol6V2P5QBnMG0kt3xqYzXE+HnGzn5WQV/ibkJ8yuMXP4+SC2hZoRaw3oAYfqhmsiMfrKgzCQ/ETTdVZnSKDCzLFtu22h6yGUO+TJrR1+3JRpOflS4V7C+wzd9ghmT0itgNs5d5aN3gkOEjr95l8VotOhV6ie+4n76a3WOYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772264157; c=relaxed/simple; bh=6sJNyE+VY1nO/tYyDnefgTdhbr4qcMLaxVtizhQQLOk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Mmr3O2JO2lSzENY5/KVILdgy1zkWzep9wUNf584SWubh96uoLXS5eILlsS8TWSKNl0pqWMrRv0gPWpm/JK/r8PX+1K5hYsMSQpKP8HcudRQrDyrVyXkoAxZQYPDfZ+F9/HFo4jaA9/ZE9KfnqcbwLiA1luZE3n/YBbM29bRIogA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N9tdtdMW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N9tdtdMW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7026C116D0; Sat, 28 Feb 2026 07:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772264156; bh=6sJNyE+VY1nO/tYyDnefgTdhbr4qcMLaxVtizhQQLOk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=N9tdtdMWAI5Ijh2x1iw7nM2tuOn7VcN+8js+7SLSFQBQ9vU2vt9oqu+EgowziSK73 sAzO21bZJQxKxmtHlu0vSUH2tGUcQRgjFGbZX7mbQPKN8WjwpFmWL8+xDtI3qS0EtF 4Jfc+10mCY+RphkrG2fcHyK/TMz2wuYQYlWWVT80/0ZLPVgACgd9amxPCn3FPf0AgL JgqFFYCABzbxFrg5KHqTTW/MBNJ7iUh+0uZMyEIV2cew4CSOzs95au6LqecDztGc2s U0mqa9zSxlhCMSe8/lU1BD692HSjIX3cPWlCgttoWYJBTO4L+PB6fHsLYOLKccSpod azry3uoyDBKgg== Date: Fri, 27 Feb 2026 23:35:53 -0800 From: Eric Biggers To: Christoph Hellwig Cc: Andrew Morton , Richard Henderson , Matt Turner , Magnus Lindholm , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "David S. Miller" , Andreas Larsson , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Herbert Xu , Dan Williams , Chris Mason , David Sterba , Arnd Bergmann , Song Liu , Yu Kuai , Li Nan , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-arch@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: cleanup the RAID5 XOR library Message-ID: <20260228073553.GL65277@quark> References: <20260226151106.144735-1-hch@lst.de> Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260226151106.144735-1-hch@lst.de> On Thu, Feb 26, 2026 at 07:10:12AM -0800, Christoph Hellwig wrote: > Hi all, > > the XOR library used for the RAID5 parity is a bit of a mess right now. > The main file sits in crypto/ despite not being cryptography and not > using the crypto API, with the generic implementations sitting in > include/asm-generic and the arch implementations sitting in an asm/ > header in theory. The latter doesn't work for many cases, so > architectures often build the code directly into the core kernel, or > create another module for the architecture code. > > Changes this to a single module in lib/ that also contains the > architecture optimizations, similar to the library work Eric Biggers > has done for the CRC and crypto libraries later. After that it changes > to better calling conventions that allow for smarter architecture > implementations (although none is contained here yet), and uses > static_call to avoid indirection function call overhead. > > A git tree is also available here: > > git://git.infradead.org/users/hch/misc.git xor-improvements > > Gitweb: > > https://git.infradead.org/?p=users/hch/misc.git;a=shortlog;h=refs/heads/xor-improvements Overall this looks great. xor_gen() really needs a KUnit test, though. Without that, how was this tested? Later we should remove some of the obsolete implementations, such as the alpha or x86 MMX ones. Those platforms have no optimized code in lib/crc/ or lib/crypto/, and I doubt anyone cares. But that should be a separate series later: porting them over unchanged is the right call for now so that this series doesn't get blocked on debates about removals... Also, I notice that no one has optimized this for the latest x86_64 CPUs by using the vpternlogd instruction to do 3-input XORs. That would be another good future project. - Eric