• Markus Stockhausen's avatar
    md/raid6 algorithms: delta syndrome functions · fe5cbc6e
    Markus Stockhausen authored
    v3: s-o-b comment, explanation of performance and descision for
    the start/stop implementation
    Implementing rmw functionality for RAID6 requires optimized syndrome
    calculation. Up to now we can only generate a complete syndrome. The
    target P/Q pages are always overwritten. With this patch we provide
    a framework for inplace P/Q modification. In the first place simply
    fill those functions with NULL values.
    xor_syndrome() has two additional parameters: start & stop. These
    will indicate the first and last page that are changing during a
    rmw run. That makes it possible to avoid several unneccessary loops
    and speed up calculation. The caller needs to implement the following
    logic to make the functions work.
    1) xor_syndrome(disks, start, stop, ...): "Remove" all data of source
    blocks inside P/Q between (and including) start and end.
    2) modify any block with start <= block <= stop
    3) xor_syndrome(disks, start, stop, ...): "Reinsert" all data of
    source blocks into P/Q between (and including) start and end.
    Pages between start and stop that won't be changed should be filled
    with a pointer to the kernel zero page. The reasons for not taking NULL
    pages are:
    1) Algorithms cross the whole source data line by line. Thus avoid
    additional branches.
    2) Having a NULL page avoids calculating the XOR P parity but still
    need calulation steps for the Q parity. Depending on the algorithm
    unrolling that might be only a difference of 2 instructions per loop.
    The benchmark numbers of the gen_syndrome() functions are displayed in
    the kernel log. Do the same for the xor_syndrome() functions. This
    will help to analyze performance problems and give an rough estimate
    how well the algorithm works. The choice of the fastest algorithm will
    still depend on the gen_syndrome() performance.
    With the start/stop page implementation the speed can vary a lot in real
    life. E.g. a change of page 0 & page 15 on a stripe will be harder to
    compute than the case where page 0 & page 1 are XOR candidates. To be not
    to enthusiatic about the expected speeds we will run a worse case test
    that simulates a change on the upper half of the stripe. So we do:
    1) calculation of P/Q for the upper pages
    2) continuation of Q for the lower (empty) pages
    Signed-off-by: default avatarMarkus Stockhausen <stockhausen@collogia.de>
    Signed-off-by: default avatarNeilBrown <neilb@suse.de>