snapraid/raid/NOTES

SnapRAID RAID library performance notes
=======================================

Scope
-----

These notes summarize performance experiments, implementation choices, rejected
ideas, current recovery optimizations, and non-obvious conclusions reached while
reviewing and tuning the SnapRAID RAID library.

The focus is the current 1..6 parity implementation, especially x86 AVX2,
AVX512BW, GFNI, SSSE3, and AArch64 NEON backends.

This is intentionally a record of what has already been tried and what was
learned from it, so that the same ideas are not repeatedly re-investigated.

The main rule is to optimize the real SnapRAID workload, not only isolated inner
loops.


Current implementation snapshot
-------------------------------

Generation:

* Current 1..6 parity generation is considered effectively closed from a
  performance point of view.

* Relevant scalar, SSE/SSSE3, AVX2, AVX512BW, NEON, RAID GFNI affine, and AES
  GFNI paths are implemented.

* RAID GFNI Horner Q is implemented where it is useful and where register
  pressure allows it.

* AVX512 128-byte processing, AVX512BW Horner, VPTERNLOGQ, VPBLENDVB, cached
  parity stores, large pre-expanded GFNI constants, and other major alternatives
  have already been investigated or rejected.

Recovery:

* The normal one-data-disk recovery with P available is already handled by
  raid_rec1of1(), which is essentially an XOR generation pass with pointer
  remapping.

* Generic REC1 non-P SIMD kernels have been locally optimized and spatially
  unrolled where useful.

* Generic REC2 non-GFNI kernels hoist coefficient tables and reuse delta nibble
  splits.

* NEON REC2 processes two 16-byte blocks per iteration, for a 32-byte recovery
  chunk.

* RECX keeps delta values in SIMD registers on the optimized paths and reuses
  pre-split low/high nibbles instead of repeatedly reconstructing them.

* Non-GFNI RECX precomputes shuffle-table pointers in C before entering the hot
  data loop.

* RAID GFNI RECX precomputes the 8-byte affine representation of every inverse
  matrix coefficient in C before entering the hot data loop.

* The main remaining RECX local cost is repeated coefficient table/matrix
  loading or broadcasting inside the data loop.

* A specialized SIMD P+Q rec2of2 path remains open. The scalar int8
  implementation already has the specialized formula.


Real workload assumptions
-------------------------

* SnapRAID processes large blocks: typically 256 KiB per data/parity block.

* A normal stripe therefore touches a large amount of memory. With 12 data
  disks, one 256 KiB stripe already means about 3 MiB of data input before
  considering parity output.

* This large-block behavior is very important. Optimizations that reread a
  source buffer, increase the number of passes, or enlarge lookup tables can be
  worse even if the inner instruction sequence looks better.

* SnapRAID uses a queue before parity data is written to disk. Real measurements
  with actual disk writes show that very small queues are worse. Performance
  improves clearly up to about queue depth 32, and still improves after that,
  but with diminishing returns.

* With 256 KiB blocks, queue depth 32 means this much parity output can be in
  flight:

      1 parity  =  8 MiB
      2 parity  = 16 MiB
      3 parity  = 24 MiB
      6 parity  = 48 MiB

  Therefore a parity block produced by the RAID kernel is normally not consumed
  immediately.

* A memory read of a 256 KiB block that is no longer cached is still very cheap
  compared with real storage I/O. Trying to keep many queued parity blocks hot
  in cache is therefore not necessarily useful.


MOVNT / non-temporal stores
---------------------------

* Generation backends use MOVNTDQ / VMOVNTDQ for parity output where applicable.

* The synthetic speedtest naturally favors non-temporal stores because generated
  parity is not consumed afterwards. This benchmark therefore measures producer
  throughput, not the complete producer -> queue -> writer pipeline.

* However, the real SnapRAID queue makes the workload much closer to the
  non-temporal case than to an immediate-consumer case.

* Cached stores could potentially help only with very short queues, where the
  writer consumes parity while it is still hot. Queue depths around 1..4 are the
  most plausible area where this could happen.

* Those very short queues are not representative of the real fastest disk
  pipeline. Real measurements already show that queues up to about 32 provide
  substantial improvements.

* At realistic queue depths, cached parity output would occupy many MiB of cache
  and could evict useful input data. MOVNT avoids this cache pollution and avoids
  normal cache allocation/write-allocate behavior for parity output.

* Conclusion: keep MOVNT for the normal generation path. Replacing MOVNT with
  cached stores is not considered an open optimization.


Typical recovery case
---------------------

* The common recovery case is one failed data disk while parity P is still
  available.

* raid_rec() selects the first available parity. Therefore, for a single data
  failure with P available, recovery uses P.

* REC1 implementations special-case ip[0] == 0 and call raid_rec1of1().

* raid_rec1of1() remaps pointers so that P is used as an XOR input and the
  failed data buffer is used as the GEN1 output, then calls raid_gen(nd, 1, ...).

* Therefore the common single-disk recovery path does NOT call
  raid_delta_gen().

* The data traffic is already close to the minimum:

      read P
      read all surviving data blocks
      XOR them
      write the recovered data block once

* There are no temporary syndrome buffers, no GF multiplication, and no matrix
  inversion in this common path.

* This means that large architectural recovery changes mostly optimize rare
  failure cases, not the usual single-disk recovery.

* Two simultaneous data disk failures are already an exceptional case in normal
  use. Three or more simultaneous data failures are even less important as
  optimization targets.


Recovery speedtest interpretation
---------------------------------

The recovery speed tests contain separate rows for the important fast paths and
for the generic recovery paths.

REC1OF1:

* The row uses ip[0] == 0.

* Every REC1 wrapper therefore enters raid_rec1of1() instead of executing its
  normal GF recovery body.

* The speed test explicitly selects the generation function used by the
  raid_rec1of1() call with raid_gen_force(1, ...).

* There is no GFNI GEN1 because PAR1 is only XOR. Therefore:

      rec1of1 avx2     -> raid_gen1_avx2
      rec1of1 gfni     -> raid_gen1_avx2

      rec1of1 avx512   -> raid_gen1_avx512bw
      rec1of1 gfni512  -> raid_gen1_avx512bw

  This is intentional. The GFNI recovery wrapper is selected, but the fast path
  naturally reduces to the best available XOR generator.

REC1:

* The generic REC1 row uses ip + 1 to avoid the PAR1 fast path.

* It therefore measures recovery from Q or a later parity and executes the
  backend-specific REC1 GF multiplication kernel.

REC2OF2:

* The row uses ip = { 0, 1 }, meaning P and Q.

* raid_rec2_int8() has an existing specialized P+Q fast path and calls
  raid_rec2of2_int8().

* Current SIMD REC2 implementations do not have the equivalent specialized P+Q
  fast path. They execute the generic 2x2 recovery algorithm with P and Q.

* This makes the row useful as a direct benchmark for deciding whether a
  specialized SIMD rec2of2 implementation is worthwhile.

REC2:

* The generic REC2 row uses ip + 1, avoiding the P+Q fast case.

* It measures the normal generic 2x2 recovery path.

Delta generation:

* Each recovery benchmark explicitly forces a matching generation backend with
  raid_gen_force() before entering the timed recovery function.

* This is important because raid_delta_gen() internally calls raid_gen().

* The benchmark therefore avoids accidentally comparing a recovery kernel while
  using an unrelated generation backend for its delta step.


raid_delta_gen() fusion
-----------------------

* A fused recovery design was studied, where selected syndromes would be
  accumulated directly instead of:

      raid_delta_gen()
      temporary parity output
      reload temporary parity
      solve recovery matrix

* The fused design could also compute only the parity rows actually selected by
  ip[].

* This matters because raid_delta_gen() currently computes:

      np = ip[nr - 1] + 1

  and raid_gen() can generate only a prefix of parity rows.

* Example:

      nr = 3
      ip = { 0, 2, 5 }

  requires GEN6 today even though only P, R and U are needed.

* A fused RECX could calculate exactly those three syndromes.

* The idea is technically valid and could reduce temporary memory traffic and
  unnecessary parity work.

* However, the common rec1of1/P case already bypasses raid_delta_gen() entirely.

* Because the main benefit applies to less common multiple-failure or missing-P
  cases, this direction was intentionally deprioritized.

* Decision: do not pursue raid_delta_gen() + REC fusion for now.


Generation: AVX512 width and unrolling
--------------------------------------

* Wider processing is not automatically faster.

* AVX512 128-byte processing was tested and can be slower than the existing
  64-byte path.

* Therefore do not assume that x2/x4 spatial unrolling, like some Linux RAID6
  kernels use, is beneficial for SnapRAID.

* The block size is already large, memory traffic is substantial, and wider
  unrolling can increase register pressure, front-end work, and AVX512 power or
  frequency effects without reducing total memory traffic.

* VPTERNLOGQ based alternatives were also tested on Zen 5 and did not improve
  performance.

* Conclusion: keep the current conservative AVX512 generation width unless a
  specific benchmark proves otherwise.


Generation: Horner
------------------

* Linux RAID6 uses the classic Horner recurrence for Q with the standard RAID
  polynomial/generator.

* A Horner-style AVX512BW non-GFNI implementation was tested on Zen 5 and did
  not improve performance.

* Therefore Horner is NOT considered an open optimization for the AVX512BW
  non-GFNI generation path.

* GFNI is different.

* For RAID GFNI generation, Horner Q is useful because multiplying by the fixed
  generator can use one fixed affine matrix instead of a different matrix for
  every data coefficient.

* RAID GFNI Horner Q is implemented as follows:

      AVX2 RAID GFNI GEN2..GEN5:
          Horner Q with fixed multiply-by-2 affine matrix resident in a register.

      AVX2 RAID GFNI GEN6:
          keep the direct-coefficient implementation because register pressure
          is too high to keep the extra fixed matrix efficiently.

      AVX512 RAID GFNI GEN2..GEN6:
          Horner Q with the fixed matrix resident in a register.

      AES GFNI:
          unchanged, direct VGF2P8MULB coefficient multiplication.

* D0/final coefficient 1 is handled directly where appropriate.

* Conclusion: GFNI Horner Q is implemented where useful. Non-GFNI AVX512BW
  Horner was tested and rejected.


GFNI field implementation
-------------------------

* AES GFNI multiplication maps naturally to VGF2P8MULB because the instruction
  uses the AES polynomial.

* Standard RAID polynomial 0x11d cannot use VGF2P8MULB directly.

* RAID GFNI therefore uses VGF2P8AFFINEQB with precomputed affine matrices.

* The global affine matrix table stores 8 bytes per coefficient.

* A generic exhaustive software test validates all coefficient/input pairs
  against the normal RAID GF multiplication table.

* Dedicated hardware affine-matrix validators were intentionally not added.
  Normal generation/recovery tests exercise the hardware path.

* RAID and AES GFNI recovery/generation have polynomial-specific names:

      *_gfni_raid
      *_gfni_aes

  with backend tags:

      gfni
      gfni512

* This naming and registration split is intentional and should be preserved.


GFNI RECX coefficient precomputation
------------------------------------

RAID GFNI RECX previously performed this dependency chain for every coefficient
inside every data chunk:

      load coefficient byte from V[]
      use it to index raid_gfaffine_raid[]
      load the 8-byte affine matrix
      broadcast the matrix
      VGF2P8AFFINEQB

The current implementation precomputes:

      uint8_t C[N * N][8]

and copies the complete 8-byte affine representation for every inverse matrix
coefficient before entering the data loop.

The hot loop therefore becomes:

      direct load/broadcast from C[]
      VGF2P8AFFINEQB

This removes the coefficient-byte -> indexed affine-table dependency from the
hot loop while keeping the compact 8-byte representation.

Important details:

* All 8 bytes must be copied. An affine matrix coefficient is not one byte.

* Using a byte array and memcpy() keeps the representation explicit and avoids
  strict-aliasing assumptions.

* AVX2 and AVX512 RAID GFNI RECX both use this precomputation.

* AES GFNI does not need this conversion because VGF2P8MULB consumes the
  coefficient byte directly.

* The remaining repeated operation is the per-chunk broadcast of the 8-byte
  affine matrix.


GFNI pre-expanded affine tables
-------------------------------

* Intel ISA-L can use pre-expanded GFNI constants, for example a 32-byte
  representation that is ready for vector use.

* For SnapRAID this would increase the RAID affine table from about 2 KiB to
  about 8 KiB.

* With large 256 KiB processing blocks, the current small 8-byte entries plus
  broadcast have a better cache-footprint tradeoff.

* No convincing reason was found to trade four times the table footprint for
  fewer broadcasts.

* Decision: keep compact 8-byte affine matrices.


Intel ISA-L comparison
----------------------

The following ISA-L ideas were examined.

1. Horner Q for GFNI RAID generation

   Useful idea. Implemented for RAID GFNI where register pressure allows it.

2. AVX512 GFNI 128-byte processing

   Tested. It can be slower. Do not use wider processing simply because more
   ZMM registers are available.

3. Source-major generic recovery loops

   Initially interesting because one source could feed several outputs.

   For the current RECX structure, the delta/syndrome working set is tiny and
   hot. Reordering loops does not obviously save important memory traffic and
   can increase register pressure.

   This is considered low priority / not useful enough.

4. Split output processing, for example 3+3 rows

   Bad fit for SnapRAID 256 KiB blocks because it requires rereading the source
   range in another pass.

   Avoid optimizations that save registers by adding full source passes.

5. Pre-expanded 32-byte GFNI constants

   Rejected because of the larger table/cache footprint described above.

6. VPBLENDVB based x2 techniques

   Tested. No benefit / worse performance.

7. Cached parity stores

   ISA-L style normal stores are not automatically suitable for SnapRAID.
   SnapRAID has large output blocks and a real queued disk-write pipeline.
   MOVNT remains the better design choice for this workload.

8. Multiple-row GFNI macros

   Interesting in isolation, but not enough reason to reread 256 KiB source
   blocks or enlarge table footprint.

9. Broad runtime dispatch/calibration

   ISA-L has broad dispatch machinery. SnapRAID already dispatches based on CPU
   features. A runtime microbenchmark selector is possible, but is not currently
   considered worth the extra complexity for the known kernels.

10. Incremental parity APIs

   Useful in other applications, but not a missing optimization in the current
   full-block SnapRAID parity-generation hot path.

Overall ISA-L conclusion:

* The important transferable idea was GFNI Horner Q, and that is already
  implemented.

* The other ISA-L techniques examined either lose on the current benchmark,
  increase source rereads, increase cache footprint, or do not match the real
  SnapRAID workload.


Linux kernel RAID6 comparison
-----------------------------

The Linux RAID6 implementation was studied as another optimization reference.

Relevant Linux characteristics include:

* x1/x2/x4 spatial kernels
* wider AVX512 processing
* explicit prefetch
* independent chains for ILP
* classic Horner Q
* runtime generator selection
* xor_syndrome/incremental interfaces
* specialized P+Q two-disk recovery

Conclusions for SnapRAID:

* Wider x2/x4 AVX512 processing is not automatically useful. 128-byte variants
  were tested and can be slower.

* Horner AVX512BW non-GFNI was tested on Zen 5 and did not improve.

* VPTERNLOGQ alternatives were tested on Zen 5 and did not improve.

* Explicit software prefetch is not currently considered a strong candidate.
  The workload already consists of long regular streams, and the existing
  memory-layout tuning is important.

* Runtime microbenchmark-based backend selection would add complexity and is low
  priority.

* xor_syndrome/incremental parity is a different API/use case and does not
  directly improve the current full-block generation path.

* The main Linux-style algorithmic recovery optimization still worth keeping as
  a TODO is specialized P+Q two-data recovery for SIMD backends.


Memory layout, displacement and stride noise
--------------------------------------------

* The memory layout is not a neutral detail.

* Fixed displacement between buffers was observed to help.

* STRIDE_NOISE behavior differs by CPU.

* On Intel, stride noise had little effect in the observed tests.

* On Zen 5, disabling stride noise caused a large throughput reduction.

* This indicates that hardware prefetch/cache behavior is already strongly
  affected by the chosen buffer layout.

* Therefore new software-prefetch or traversal changes should not be assumed to
  help. They must be benchmarked against the existing displacement/stride
  behavior.

* This is another reason to avoid adding extra passes over 256 KiB blocks.


REC1 optimizations
------------------

The important normal REC1 case is already raid_rec1of1() with P and is close to
the minimum possible memory traffic.

For generic REC1, used when P is unavailable:

* AVX2 processes 64 bytes per iteration using two independent 32-byte chains.

* SSSE3 x86-64 processes 64 bytes per iteration using four independent 16-byte
  chains. The x86-32 path keeps the smaller register-compatible fallback.

* NEON processes 64 bytes per iteration using four independent 16-byte chains.

The arithmetic work per byte is mostly unchanged. The purpose of the unrolling
is:

* reduce loop-control overhead
* expose more independent work
* improve instruction scheduling around shuffle/table operations

This is a local optimization, not an architectural change.

REC1 status:

* rec1of1/P is essentially closed.

* Generic non-P REC1 may still receive small local tuning if measurements show a
  clear benefit.

* No major REC1 algorithmic optimization is currently expected.


REC2 optimizations
------------------

Generic non-GFNI REC2 table/broadcast hoisting is implemented.

AVX2 x86-64:

* keep the 8 low/high shuffle tables for V0..V3 resident in ymm8..ymm15
* keep the low-nibble mask resident
* split d0/d1 once per chunk
* reuse the split values for both recovered outputs

AVX512BW:

* keep the 8 low/high shuffle tables resident in zmm16..zmm23
* keep the low-nibble mask resident
* split d0/d1 once per chunk
* reuse the split values for both recovered outputs

SSSE3 x86-64:

* keep all four coefficient low/high tables in XMM registers
* split both deltas once
* reuse the split values for both outputs

NEON:

* keep the four low/high coefficient tables in v20..v27
* keep the low-nibble mask in v28
* process two independent 16-byte blocks per iteration
* split both deltas once per block
* reuse the split values for both outputs
* the 32-byte unrolled kernel uses 25 vector registers

Important portability result:

* x86-32 has only the low eight XMM/YMM registers available to these old ISA
  paths.

* Optimizations that depend on xmm8..xmm15 or ymm8..ymm15 must remain restricted
  to CONFIG_X86_64.

REC2 status:

* Generic REC2 local table/split reuse is implemented.

* Scalar int8 already has specialized rec2of2 P+Q recovery.

* Specialized SIMD rec2of2 P+Q remains open.


Specialized rec2of2 P+Q
-----------------------

For failures of two data disks recovered specifically with P and Q, the system
can be reduced to:

      Dy = C0 * Pd ^ C1 * Qd
      Dx = Pd ^ Dy

This needs only two GF multiplications for Dy, followed by one XOR for Dx,
instead of the generic 2x2 reconstruction with four GF multiplications.

The scalar int8 implementation already uses this specialization.

Current SIMD REC2 backends still use the generic 2x2 matrix solution even when
ip = { 0, 1 }.

Potential targets include:

* SSSE3
* AVX2
* AVX512BW
* AVX2 GFNI
* AVX512 GFNI
* NEON

The new rec2of2 benchmark row exists specifically to measure whether these
specializations are worth adding.

Practical priority remains low because simultaneous loss of two data disks is an
exceptional real-world case.


RECX delta handling
-------------------

RECX previously had avoidable temporary-buffer and repeated split work.

The current optimized structure keeps the delta values for the current data
chunk in SIMD registers.

For non-GFNI paths:

* each delta is split into low/high nibbles once
* the split values remain in SIMD registers while all recovered outputs are
  calculated
* the same split values are reused across output rows
* stack temporary delta buffers are avoided on the optimized paths

For GFNI paths:

* the byte deltas remain directly in SIMD registers
* no nibble split is needed

This closes the old questions:

      can pd[k] stay in a register longer?
      can low/high nibble splits be reused across outputs?

For the current optimized paths, the answer is yes and this work is implemented.


RECX shuffle-table pointer precomputation
----------------------------------------

Non-GFNI RECX previously performed coefficient address calculation inside the
hot loop:

      load coefficient byte from V[]
      multiply the coefficient index by 32
      add the raid_gfmulpshufb base address
      load low/high shuffle tables

The current implementation precomputes in C:

      T[j] = &raid_gfmulpshufb[V[j]][0][0];

The hot assembly then only performs:

      load T[j]
      load or broadcast low table at T[j] + 0
      load or broadcast high table at T[j] + 16

This has two advantages:

1. It removes coefficient-index address arithmetic from the hot assembly.

2. It keeps C object layout and address calculation in C, leaving the assembly
   focused on SIMD operations.

Current users include:

* AVX2 RECX x86-64
* AVX512BW RECX
* SSSE3 RECX x86-64
* NEON RECX

For x86-32 AVX2/SSSE3 fallbacks, T[] is not unnecessarily built when the old
fallback body does not use it.

The remaining cost is that the low/high tables are still loaded or broadcast for
every coefficient of every data chunk.


RECX current register state
---------------------------

The current RECX structure already uses registers aggressively.

AVX512BW:

* up to six delta values are kept as low/high pairs in zmm0..zmm11
* zmm12..zmm15 are reconstruction temporaries/accumulators
* zmm31 keeps the low-nibble mask
* coefficient shuffle tables are still broadcast from T[] during reconstruction

AVX512 RAID GFNI:

* up to six byte deltas are kept in zmm0..zmm5
* temporary/accumulator registers are used for reconstruction
* coefficient affine matrices come directly from precomputed C[]
* one 8-byte affine matrix is still broadcast per coefficient per chunk

AVX2 RAID GFNI:

* the two 32-byte halves of up to six delta blocks occupy most of the available
  YMM register file
* C[] removes indexed affine-table lookup
* register pressure leaves less room for keeping many coefficient matrices
  resident

AVX2/SSSE3 non-GFNI:

* the optimized x86-64 paths keep pre-split deltas in vector registers
* register pressure is significantly higher than AVX512
* coefficient table residency is therefore much more constrained

NEON:

* pre-split deltas are kept in vector registers
* T[] provides direct pointers to low/high multiplication tables
* reconstruction still loads each coefficient table pair as needed


RECX remaining local optimization
---------------------------------

The main RECX question that remains genuinely open is:

      can repeated coefficient loads/broadcasts be reduced by keeping useful
      coefficient tables or affine matrices resident in spare vector registers?

This is most plausible on AVX512 because of the larger register file.

Possible experiments:

* keep one output row of coefficients resident across data chunks

* keep a useful prefix of coefficient tables resident when N permits it

* on AVX512 RAID GFNI, keep several 8-byte affine matrices broadcast in ZMM
  registers instead of broadcasting them again for every chunk

* on AVX512BW, keep some low/high shuffle-table pairs resident

Constraints:

* Do not add a second pass over the 256 KiB block.

* Do not spill deltas or accumulators merely to save coefficient broadcasts.

* Do not add large N-specific kernel families unless measurements justify the
  complexity.

* AVX2 and SSSE3 register pressure is already high, so the likely opportunity is
  much smaller there.

* NEON has more architectural registers than old x86 SIMD but current RECX
  already uses a significant part of them; any residency experiment should be
  measured carefully.

This is now a narrower problem than the old RECX TODO list. Delta residency,
nibble reuse, coefficient address precomputation, and GFNI affine lookup
precomputation are already implemented.


Recovery optimization policy from now on
-----------------------------------------

For recovery, avoid new architecture-level changes unless a very strong case
appears.

Preferred optimizations are basic/local:

* hoist loop-invariant values
* keep masks/tables/matrices resident when register pressure allows it
* avoid repeated loads or broadcasts
* initialize accumulators from the first useful term
* keep address calculations in C when doing so simplifies inline assembly
* exploit coefficient 0 or 1 only when it stays simple and does not add harmful
  branching or complexity
* use limited spatial unrolling only when it exposes ILP without excessive
  register pressure

Avoid for now:

* raid_delta_gen() fusion
* extra full passes over source blocks
* aggressive spatial unrolling
* software prefetch without clear evidence
* changing MOVNT policy
* major loop-orientation changes
* large pre-expanded lookup tables
* broad runtime calibration machinery


Inline assembly and portability constraints
-------------------------------------------

The SIMD code intentionally uses multiple small or large asm volatile blocks and
keeps SIMD state live across them.

Important project constraints:

* Assembly blocks that dereference pointers internally must model memory effects
  appropriately. RECX pointer-based blocks use a "memory" clobber.

* The x86 SSE/AVX end helpers declare SIMD clobbers needed by the project ABI
  strategy, including the Windows x64 callee-saved XMM registers.

* The NEON end helper declares v0..v31 clobbered so that GCC/Clang preserve
  AAPCS64 callee-saved v8..v15 when required.

* The end-of-function dummy-clobber mechanism is a documented project technique.
  It is not a fully explicit extended-asm dataflow model, so future compiler
  portability changes should be reviewed carefully.

* Do not assume x86-32 has xmm8..xmm15 or ymm8..ymm15.

* RAID block sizes passed to the SIMD code are multiples of 64, so current
  32-byte and 64-byte unrolled loops do not need tail handling.

These are established implementation constraints, not current correctness
findings.


Generation status
-----------------

For current 1..6 parity generation, performance work is considered largely
closed.

Already covered:

* scalar/int paths
* SSE/SSSE3/AVX2/AVX512 paths
* NEON paths
* GFNI RAID affine generation
* GFNI AES direct multiplication
* RAID GFNI Horner Q
* AVX512 width experiments
* VPTERNLOGQ experiments
* VPBLENDVB experiments
* MOVNT policy
* memory displacement/stride behavior
* ISA-L comparisons
* Linux RAID6 comparisons

No major generation optimization remains that currently has a strong reason to
be tested.


More than 6 parity levels
-------------------------

* Supporting more than 6 parity levels remains a future feature.

* A generic implementation using SSSE3/AVX intrinsics could be compared with the
  current handwritten assembler style.

* This is primarily a functional extension, not an unresolved performance issue
  for the current 1..6 parity library.


Current practical priority
--------------------------

1. Use the new rec2of2 benchmark to decide whether specialized SIMD P+Q recovery
   is worth implementing.

2. Recovery only: inspect RECX for coefficient table/matrix residency, especially
   AVX512BW and AVX512 GFNI.

3. Prefer small local improvements that reduce broadcasts or repeated loads
   without changing memory traversal.

4. Treat REC1 and generic REC2 as largely locally optimized unless benchmarks
   expose a clear new bottleneck.

5. Do not reopen generation width, MOVNT, non-GFNI AVX512BW Horner,
   VPTERNLOGQ, VPBLENDVB, large GFNI tables, source rereads, or
   raid_delta_gen() fusion unless new hardware or new measurements provide a
   concrete reason.


Short list of ideas already implemented
---------------------------------------

* Common one-disk + P recovery through raid_rec1of1().

* Generic REC1 64-byte local unrolling for AVX2, x86-64 SSSE3, and NEON.

* x86-64 non-GFNI REC2 coefficient-table residency.

* AVX512BW REC2 coefficient-table residency.

* NEON REC2 32-byte unrolling with two independent blocks.

* RECX delta values kept in vector registers on optimized paths.

* RECX low/high nibble splitting performed once and reused across outputs.

* RECX stack temporary delta buffers removed on optimized paths.

* Non-GFNI RECX shuffle-table addresses precomputed as T[] pointers in C.

* RAID GFNI RECX affine coefficient representations precomputed as C[][8].

* RECX accumulators initialized from useful products where the current kernels
  allow it.

* Recovery speedtest rows for rec1of1 and rec2of2.


Short list of ideas already tried or rejected
---------------------------------------------

* AVX512 128-byte generation processing:
  tried, can be slower.

* AVX512BW Horner:
  tried on Zen 5, no improvement.

* VPTERNLOGQ optimization:
  tried on Zen 5, no improvement.

* VPBLENDVB x2:
  tried, no benefit / worse.

* MOVNT -> cached stores:
  not appropriate for the normal queued disk-write workload; keep MOVNT.

* GFNI 32-byte pre-expanded affine constants:
  rejected due to larger cache footprint.

* Split GFNI outputs into multiple passes:
  rejected because 256 KiB source blocks would be reread.

* RECX source-major rewrite:
  low priority; hot tiny delta working set and register-pressure tradeoff.

* raid_delta_gen() + REC fusion:
  technically valid but intentionally deprioritized because the normal
  rec1of1/P case bypasses raid_delta_gen() already.

* Software prefetch:
  no strong reason to add it given the existing long streams and proven
  sensitivity to displacement/stride tuning.

* Runtime backend microbenchmark selection:
  possible, but low value relative to complexity.

* Linux x2/x4 style wide generation kernels:
  not assumed useful; wider AVX512 has already tested negatively.

* ISA-L cached-store behavior:
  not a good match for the real SnapRAID parity queue.

* ISA-L source reread / split-output strategies:
  poor fit for 256 KiB blocks.


Open items
----------

For the current 1..6 parity implementation, the open list is intentionally
short.

1. Specialized SIMD rec2of2 P+Q recovery

   The scalar int8 specialization exists.

   Use the rec2of2 speedtest row to quantify whether SIMD specializations are
   worthwhile.

2. RECX coefficient residency

   Investigate whether AVX512BW and AVX512 GFNI can keep useful coefficient
   tables/matrices resident across chunks and remove repeated broadcasts.

   AVX2, SSSE3, and NEON may have smaller opportunities, but register pressure
   must be respected.

3. Minor recovery micro-optimizations

   Only pursue small invariant-hoisting, load/broadcast reduction, or scheduling
   improvements supported by benchmarks.

4. More than 6 parity levels

   Future functional feature, not a current 1..6 performance problem.


End state
---------

For the current 1..6 parity RAID library:

    Generation:          effectively closed
    GFNI generation:     effectively closed
    Store policy:        closed, keep MOVNT
    Memory layout:       tuned; do not casually change
    REC1 common P path:  effectively closed
    REC1 generic:        local tuning only
    REC2 generic:        substantially locally optimized
    rec2of2 SIMD P+Q:    open TODO, benchmark now available
    RECX delta reuse:    implemented
    RECX address setup:  implemented with T[] / C[]
    RECX broadcasts:     main remaining local optimization area
    >6 parity:           future feature

The most important workload fact to remember is that normal recovery is a
single failed data disk with P available. That path goes through
raid_rec1of1() and is already a direct XOR-style recovery with minimal extra
work.