forked from luck/tmp_suning_uos_patched
f591df3cc6
There are several algorithms available for raid6 to generate xor and syndrome
parity, including basic int1, int2 ... int32 and SIMD optimized implementation
like sse and neon. To test and choose the best algorithms at the initial
stage, we need provide enough disk data to feed the algorithms. However, the
disk number we provided depends on page size and gfmul table, seeing bellow:
const int disks = (65536/PAGE_SIZE) + 2;
So when come to 64K PAGE_SIZE, there is only one data disk plus 2 parity disk,
as a result the chosed algorithm is not reliable. For example, on my arm64
machine with 64K page enabled, it will choose intx32 as the best one, although
the NEON implementation is better.
This patch tries to fix the problem by defining a constant raid6 disk number to
supporting arbitrary page size.
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Zhengyuan Liu <liuzhengyuan@kylinos.cn>
Signed-off-by: Song Liu <songliubraving@fb.com>
|
||
|---|---|---|
| .. | ||
| test | ||
| .gitignore | ||
| algos.c | ||
| altivec.uc | ||
| avx2.c | ||
| avx512.c | ||
| int.uc | ||
| Makefile | ||
| mktables.c | ||
| mmx.c | ||
| neon.c | ||
| neon.uc | ||
| recov_avx2.c | ||
| recov_avx512.c | ||
| recov_neon_inner.c | ||
| recov_neon.c | ||
| recov_s390xc.c | ||
| recov_ssse3.c | ||
| recov.c | ||
| s390vx.uc | ||
| sse1.c | ||
| sse2.c | ||
| unroll.awk | ||
| vpermxor.uc | ||
| x86.h | ||