[PATCH v3 0/3] lib/raid6: Optimize raid6_select_algo to ensure

sunliming@linux.dev posted 3 patches 1 month, 2 weeks ago
There is a newer version of this series
include/linux/raid/pq.h |  3 --
lib/Kconfig             |  8 ----
lib/raid6/algos.c       | 88 ++++++++++++++++++++++++++++++-----------
3 files changed, 65 insertions(+), 34 deletions(-)
[PATCH v3 0/3] lib/raid6: Optimize raid6_select_algo to ensure
Posted by sunliming@linux.dev 1 month, 2 weeks ago
From: sunliming <sunliming@kylinos.cn>

The selection of RAID6 PQ functions involves a dual-strategy approach:
prioritizing startup speed leads to quickly choosing a usable algorithm,
while prioritizing performance leads to selecting an optimal algorithm
via benchmarking. This choice is determined by the RAID6_PQ_BENCHMARK
configuration. This patch series achieves both fast startup and optimal
algorithm selection by initially choosing an algorithm quickly at startup,
then asynchronously determining the optimal algorithm through benchmarking.
Since all RAID6 PQ function algorithms are functionally equivalent despite
performance differences, this approach should be effective.

---
Changes in v3:
  Remove the __init annotation from raid6_benchmark_work and benchmark_work_func,
as they are still referenced during initialization.
Changes in v2:
  Select the highest-priority algorithm instead of the first one. 
  Add the cancel_work_sync function in the exit function to handle the 
work queue cleanup.
--- 
sunliming (3):
  ib/raid6: Divide the raid6 algorithm selection process into two parts
  lib/raid6: Optimizing the raid6_select_algo time through asynchronous
    processing
  lib/raid6: Delete the RAID6_PQ_BENCHMARK config

 include/linux/raid/pq.h |  3 --
 lib/Kconfig             |  8 ----
 lib/raid6/algos.c       | 88 ++++++++++++++++++++++++++++++-----------
 3 files changed, 65 insertions(+), 34 deletions(-)

-- 
2.25.1
Re: [PATCH v3 0/3] lib/raid6: Optimize raid6_select_algo to ensure
Posted by Christoph Hellwig 1 month, 2 weeks ago
This is actually a very bad idea.

The current indirect calls for the raid parity generation are very
expensive and need to be replaced by static calls.  Doing runtime
switching defeats this.

I had started on doing the static calls a while ago, let me try to
finish that off.