On Thu, Mar 10, 2022 at 2:15 PM Jens Axboe <axboe@xxxxxxxxx> wrote: > > On 3/8/22 11:42 PM, Song Liu wrote: > > RAID arrays check/repair operations benefit a lot from merging requests. > > If we only check the previous entry for merge attempt, many merge will be > > missed. As a result, significant regression is observed for RAID check > > and repair. > > > > Fix this by checking more than just the previous entry when > > plug->multiple_queues == true. > > > > This improves the check/repair speed of a 20-HDD raid6 from 19 MB/s to > > 103 MB/s. > > Do the underlying disks not have an IO scheduler attached? Curious why > the merges aren't being done there, would be trivial when the list is > flushed out. Because if the perf difference is that big, then other > workloads would be suffering they are that sensitive to being within a > plug worth of IO. The disks have mq-deadline by default. I also tried kyber, the result is the same. Raid repair work sends IOs to all the HDDs in a round-robin manner. If we only check the previous request, there isn't much opportunity for merge. I guess other workloads may have different behavior? > Between your two approaches, I do greatly prefer the first one though. I also like the first one better. But I am not sure whether it will slow down other workloads. We can probably also make the second one cleaner with a new variation of blk_start_plug. Thanks, Song
