On Thu, Mar 19, 2009 at 9:06 AM, H. Peter Anvin <h.peter.anvin@xxxxxxxxx> wrote:
> Dan Williams wrote:
>> + * @scfs: array of source coefficients used in GF-multiplication
>
> Array of source coefficients? Are you doing a vector-vector
> multiplication here?
>
> Given this code:
>
>> for (d = 0; d < len; d++) {
>> + wq = wp = ptrs[0][d];
>> + for (z = 1; z < src_cnt; z++) {
>> + wd = ptrs[z][d];
>> + wp ^= wd;
>> + wq ^= raid6_gfmul[scfs[z]][wd];
>> + }
>
> ... it kinds of looks like that.
>
> This is really quite expensive! The whole point of the restore code
> that exists is that we never do a two-dimensional lookup, instead
> caching a pointer to the multiplication table that we intend to use,
> because the RAID-6 code only ever contains scalar-vector multiplications.
>
> I really don't get this, and I think it's broken.
Something is broken if we take this path. This routine could stand to
have a WARN_ONCE(), because if it is ever called there is something is
wrong with the raid6 offload driver. The intent is that the
asynchronous recovery routines will perform an early check to see if
the recovery can be offloaded (with a series of calls to
async_xor/async_pq). If not we fall back to the optimized synchronous
recovery routines (raid6_2data_recov, raid6_datap_recov). The only
time this path will be taken is if we have decided to perform
asynchronous recovery but at a later call to async_pq the offload
driver reports it has run out of descriptors.
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
