<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/lib/raid6, branch v6.8</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.8</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.8'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-12-11T13:33:07Z</updated>
<entry>
<title>s390/fpu: get rid of MACHINE_HAS_VX</title>
<updated>2023-12-11T13:33:07Z</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2023-12-01T14:42:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=18564756ab328dfdc84d09b8150f5e4d2bb96753'/>
<id>urn:sha1:18564756ab328dfdc84d09b8150f5e4d2bb96753</id>
<content type='text'>
Get rid of MACHINE_HAS_VX and replace it with cpu_has_vx() which is a
short readable wrapper for "test_facility(129)".

Facility bit 129 is set if the vector facility is present. test_facility()
returns also true for all bits which are set in the architecture level set
of the cpu that the kernel is compiled for. This means that
test_facility(129) is a compile time constant which returns true for z13
and later, since the vector facility bit is part of the z13 kernel ALS.

In result the compiled code will have less runtime checks, and less code.

Reviewed-by: Hendrik Brueckner &lt;brueckner@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>lib/raid6: Drop IA64 support</title>
<updated>2023-09-11T08:13:18Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2023-01-13T17:08:32Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b089ea3cc30de85ea7e20aa66500feb4082dfbf7'/>
<id>urn:sha1:b089ea3cc30de85ea7e20aa66500feb4082dfbf7</id>
<content type='text'>
Drop Itanium support from the RAID6 code, and along with it, the 16x and
32x unrolled versions, which were only used by IA64.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>raid6: Add LoongArch SIMD recovery implementation</title>
<updated>2023-09-06T14:53:55Z</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2023-09-06T14:53:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f2091321044d9fbcadb93dfc1c9cf23e563ea40c'/>
<id>urn:sha1:f2091321044d9fbcadb93dfc1c9cf23e563ea40c</id>
<content type='text'>
Similar to the syndrome calculation, the recovery algorithms also work
on 64 bytes at a time to align with the L1 cache line size of current
and future LoongArch cores (that we care about). Which means
unrolled-by-4 LSX and unrolled-by-2 LASX code.

The assembly is originally based on the x86 SSSE3/AVX2 ports, but
register allocation has been redone to take advantage of LSX/LASX's 32
vector registers, and instruction sequence has been optimized to suit
(e.g. LoongArch can perform per-byte srl and andi on vectors, but x86
cannot).

Performance numbers measured by instrumenting the raid6test code, on a
3A5000 system clocked at 2.5GHz:

&gt; lasx  2data: 354.987 MiB/s
&gt; lasx  datap: 350.430 MiB/s
&gt; lsx   2data: 340.026 MiB/s
&gt; lsx   datap: 337.318 MiB/s
&gt; intx1 2data: 164.280 MiB/s
&gt; intx1 datap: 187.966 MiB/s

Because recovery algorithms are chosen solely based on priority and
availability, lasx is marked as priority 2 and lsx priority 1. At least
for the current generation of LoongArch micro-architectures, LASX should
always be faster than LSX whenever supported, and have similar power
consumption characteristics (because the only known LASX-capable uarch,
the LA464, always compute the full 256-bit result for vector ops).

Acked-by: Song Liu &lt;song@kernel.org&gt;
Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>raid6: Add LoongArch SIMD syndrome calculation</title>
<updated>2023-09-06T14:53:55Z</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2023-09-06T14:53:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8f3f06dfd6873135068ccf1a0b386308e8c4da38'/>
<id>urn:sha1:8f3f06dfd6873135068ccf1a0b386308e8c4da38</id>
<content type='text'>
The algorithms work on 64 bytes at a time, which is the L1 cache line
size of all current and future LoongArch cores (that we care about), as
confirmed by Huacai. The code is based on the generic int.uc algorithm,
unrolled 4 times for LSX and 2 times for LASX. Further unrolling does
not meaningfully improve the performance according to experiments.

Performance numbers measured during system boot on a 3A5000 @ 2.5GHz:

&gt; raid6: lasx     gen() 12726 MB/s
&gt; raid6: lsx      gen() 10001 MB/s
&gt; raid6: int64x8  gen()  2876 MB/s
&gt; raid6: int64x4  gen()  3867 MB/s
&gt; raid6: int64x2  gen()  2531 MB/s
&gt; raid6: int64x1  gen()  1945 MB/s

Comparison of xor() speeds (from different boots but meaningful anyway):

&gt; lasx:    11226 MB/s
&gt; lsx:     6395 MB/s
&gt; int64x4: 2147 MB/s

Performance as measured by raid6test:

&gt; raid6: lasx     gen() 25109 MB/s
&gt; raid6: lsx      gen() 13233 MB/s
&gt; raid6: int64x8  gen()  4164 MB/s
&gt; raid6: int64x4  gen()  6005 MB/s
&gt; raid6: int64x2  gen()  5781 MB/s
&gt; raid6: int64x1  gen()  4119 MB/s
&gt; raid6: using algorithm lasx gen() 25109 MB/s
&gt; raid6: .... xor() 14439 MB/s, rmw enabled

Acked-by: Song Liu &lt;song@kernel.org&gt;
Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>raid6: test: only check for Altivec if building on powerpc hosts</title>
<updated>2023-08-15T16:40:27Z</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2023-07-31T10:49:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7b3c70c43c13ad8e59f5561b154663d6bdb77021'/>
<id>urn:sha1:7b3c70c43c13ad8e59f5561b154663d6bdb77021</id>
<content type='text'>
Altivec is only available for powerpc hosts, so only check for its
availability when the host is powerpc, to avoid error messages being
shown on architectures other than x86, arm or powerpc.

Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Link: https://lore.kernel.org/r/20230731104911.411964-6-kernel@xen0n.name
Signed-off-by: Song Liu &lt;song@kernel.org&gt;
</content>
</entry>
<entry>
<title>raid6: test: make sure all intermediate and artifact files are .gitignored</title>
<updated>2023-08-15T16:40:27Z</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2023-07-31T10:49:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6601f5e122e5fdcea0fa5eaa54b88b02dbc9ec07'/>
<id>urn:sha1:6601f5e122e5fdcea0fa5eaa54b88b02dbc9ec07</id>
<content type='text'>
Currently when the raid6test utility is built, the resulting binary and
an int.uc file are not being ignored, which can get inadvertently
committed as a result when one works on the raid6 code. Ignore them to
make `git status` clean at all times.

Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Link: https://lore.kernel.org/r/20230731104911.411964-5-kernel@xen0n.name
Signed-off-by: Song Liu &lt;song@kernel.org&gt;
</content>
</entry>
<entry>
<title>raid6: test: cosmetic cleanups for the test Makefile</title>
<updated>2023-08-15T16:40:27Z</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2023-07-31T10:49:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2008d89fb6435a3a900b72b856a18e0cc0d2c057'/>
<id>urn:sha1:2008d89fb6435a3a900b72b856a18e0cc0d2c057</id>
<content type='text'>
Use tabs/spaces consistently: hard tabs for marking recipe lines only,
spaces for everything else.

Also, the OPTFLAGS declaration actually included the tabs preceding the
line comment, making compiler invocation lines unnecessarily long. As
the entire block of declarations are meant for ad-hoc customization
(otherwise they would probably make use of `?=` instead of `=`), move
the "Adjust as desired" comment above the block too to fix the long
invocation lines.

Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Link: https://lore.kernel.org/r/20230731104911.411964-4-kernel@xen0n.name
Signed-off-by: Song Liu &lt;song@kernel.org&gt;
</content>
</entry>
<entry>
<title>raid6: guard the tables.c include of &lt;linux/export.h&gt; with __KERNEL__</title>
<updated>2023-08-15T16:40:27Z</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2023-07-31T10:49:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9dd6e1da811ffad95a79b2690110ef1bbaf4dda4'/>
<id>urn:sha1:9dd6e1da811ffad95a79b2690110ef1bbaf4dda4</id>
<content type='text'>
The export directives for the tables are already emitted with __KERNEL__
guards, but the &lt;linux/export.h&gt; include is not, causing errors when
building the raid6test program. Guard this include too to fix the
raid6test build.

Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Link: https://lore.kernel.org/r/20230731104911.411964-3-kernel@xen0n.name
Signed-off-by: Song Liu &lt;song@kernel.org&gt;
</content>
</entry>
<entry>
<title>raid6: remove the &lt;linux/export.h&gt; include from recov.c</title>
<updated>2023-08-15T16:40:27Z</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2023-07-31T10:49:07Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5afcf28d07dee91e48d1c809ebd19c3bfc403765'/>
<id>urn:sha1:5afcf28d07dee91e48d1c809ebd19c3bfc403765</id>
<content type='text'>
There is no exported symbol left in recov.c, so the include is now
unnecessary, and breaks the raid6test build. Remove it.

Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Link: https://lore.kernel.org/r/20230731104911.411964-2-kernel@xen0n.name
Signed-off-by: Song Liu &lt;song@kernel.org&gt;
</content>
</entry>
<entry>
<title>raid6: neon: add missing prototypes</title>
<updated>2023-06-13T22:13:20Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2023-05-17T13:22:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3de13550a20fd570441c0f854abe58c6cc46c0bc'/>
<id>urn:sha1:3de13550a20fd570441c0f854abe58c6cc46c0bc</id>
<content type='text'>
The raid6 syndrome functions are generated for different sizes and have
no generic prototype, while in the inner functions have a prototype
in a header that cannot be included from the correct file. In both
cases, the compiler warns about missing prototypes:

lib/raid6/recov_neon_inner.c:27:6: warning: no previous prototype for '__raid6_2data_recov_neon' [-Wmissing-prototypes]
lib/raid6/recov_neon_inner.c:77:6: warning: no previous prototype for '__raid6_datap_recov_neon' [-Wmissing-prototypes]
lib/raid6/neon1.c:56:6: warning: no previous prototype for 'raid6_neon1_gen_syndrome_real' [-Wmissing-prototypes]
lib/raid6/neon1.c:86:6: warning: no previous prototype for 'raid6_neon1_xor_syndrome_real' [-Wmissing-prototypes]
lib/raid6/neon2.c:56:6: warning: no previous prototype for 'raid6_neon2_gen_syndrome_real' [-Wmissing-prototypes]
lib/raid6/neon2.c:97:6: warning: no previous prototype for 'raid6_neon2_xor_syndrome_real' [-Wmissing-prototypes]
lib/raid6/neon4.c:56:6: warning: no previous prototype for 'raid6_neon4_gen_syndrome_real' [-Wmissing-prototypes]
lib/raid6/neon4.c:119:6: warning: no previous prototype for 'raid6_neon4_xor_syndrome_real' [-Wmissing-prototypes]
lib/raid6/neon8.c:56:6: warning: no previous prototype for 'raid6_neon8_gen_syndrome_real' [-Wmissing-prototypes]
lib/raid6/neon8.c:163:6: warning: no previous prototype for 'raid6_neon8_xor_syndrome_real' [-Wmissing-prototypes]

Add a new header file that contains the prototypes for both to avoid
the warnings.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Song Liu &lt;song@kernel.org&gt;
Link: https://lore.kernel.org/r/20230517132220.937200-1-arnd@kernel.org
</content>
</entry>
</feed>
