Hi, give me a few days, unfortunately my time is very limited. Thanks for reporting this interesting problem, Paolo > Il giorno 16 gen 2021, alle ore 09:59, yukuai (C) <yukuai3@xxxxxxxxxx> ha scritto: > > ping... > > On 2021/01/11 21:15, yukuai (C) wrote: >> Hi, >> We found a performance problem: >> kernel version: 5.10 >> disk: ssd >> scheduler: bfq >> arch: arm64 / x86_64 >> test param: direct=1, ioengine=psync, bs=4k, rw=randread, numjobs=32 >> We are using 32 threads here, test results showed that iops is equal >> to single thread. >> After digging into the problem, I found root cause of the problem is strange: >> bfq_add_request >> bfq_bfqq_handle_idle_busy_switch >> bfq_add_bfqq_busy >> bfq_activate_bfq >> bfq_activate_requeue_entity >> __bfq_activate_requeue_entity >> __bfq_activate_entity >> if (!bfq_entity_to_bfqq(entity)) >> if (!entity->in_groups_with_pending_reqs) >> entity->in_groups_with_pending_reqs = true; >> bfqd->num_groups_with_pending_reqs++ >> If test process is not in root cgroup, num_groups_with_pending_reqs will >> be increased after request was instered to bfq. >> bfq_select_queue >> bfq_better_to_idle >> idling_needed_for_service_guarantees >> bfq_asymmetric_scenario >> return varied_queue_weights || multiple_classes_busy || bfqd->num_groups_with_pending_reqs > 0 >> After issuing IO to driver, num_groups_with_pending_reqs is ensured to >> be nonzero, thus bfq won't expire the queue. This is the root cause of >> degradating to single-process performance. >> One the other hand, if I set slice_idle to zero, bfq_better_to_idle will >> return false early, and the problem will disapear. However, relative >> control will be inactive. >> My question is that, is this a known flaw for bfq? If not, as cfq don't >> have such problem, is there a suitable solution? >> Thanks! >> Yu Kuai >> such problem,
