Il 2022-01-23 23:52 Dave Chinner ha scritto:
CFQ doesn't understand that IO from different threads/tasks are
related and so it cannot account for/control multi-threaded IO
workloads. Given that XFS's journal IO is inherently a
multi-threaded IO workload, CFQ IO accounting and throttling simply
does not work properly with XFS or any other filesystem that
decouples IO from the user task context that requires the IO to be
done on it's behalf.
Hi Dave,
ah, so it forces all threads under the same time slice? I thought it was
thread aware...
Is it the same even for BFQ?
And, as per above, that's exactly why it doesn't work well with XFS...
Read starvation during sequential writes sounds more like a problem
with the block layer writeback throttle or something you need to
use an IO controller (blk-cgroups) to address, not try to fix with a
IO scheduler...
To tell the truth, I simply disabled NCQ on the affected drive. I don't
think anything is wrong with the block layer simply because I can
constantly replicate the random read starvation by running, at the same
time, the following fio commands against the raw block device:
fio --name=test --filename=/dev/sda --direct=1 --rw=read --runtime=30
#seq read
fio --name=test --filename=/dev/sda --direct=1 --rw=randread
--runtime=30 #rnd read
The first fio sucks almost any resources, leaving the randread process
with ~2 IOPS with frequent drops to 0.
Using CFQ seems to avoid total starvation, but I then remembered it has
some scalability and performance issues.
Disabling NCQ solves the issue, at the cost of not using any hardware
queue (obviously).
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
