Bug 2400 - [ANCK 4.19] io.bfq.weight has no effect
Summary: [ANCK 4.19] io.bfq.weight has no effect
Status: CONFIRMED
Alias: None
Product: ANCK 4.19 Dev
Classification: ANCK
Component: block/storage (show other bugs) block/storage
Version: 4.19-026.x
Hardware: x86_64 Linux
: P3-Medium S3-normal
Target Milestone: ---
Assignee: Joseph Qi
QA Contact: shuming
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-14 17:28 UTC by chuanguo
Modified: 2023-03-02 18:14 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chuanguo 2022-10-14 17:28:15 UTC
Anolis OS 8.6            4.19.91-26.an8.x86_64


Cgroupv2,

The business runs in different Dockers and belongs to different Cgroups.

There is a backup service with a low priority. I hope it will not affect the services with a high priority.

However, when high-priority services do not perform I/O, backup services should  run at full capacity

The following test doesn't seem to work,


Steps to Reproduce:
mount /dev/sda1 /wcg/data2/
echo bfq > /sys/block/sda/queue/scheduler
echo 0 > /sys/block/sda/queue/iosched/low_latency

cd /sys/fs/cgroup/
mkdir fio1 fio2
echo "+io +memory" > cgroup.subtree_control

echo 50 > fio1/io.bfq.weight
echo 100 > fio2/io.bfq.weight

echo $$ > fio1/cgroup.procs
fio -rw=write -ioengine=libaio -bs=4k -size=3G -numjobs=8 -iodepth 8 -thread -name=/wcg/data2/fio_test1.log

#do follow at another terminal
echo $$ > /sys/fs/cgroup/fio2/cgroup.procs
fio -rw=write -ioengine=libaio -bs=4k -size=3G -numjobs=8 -iodepth 8 -thread -name=/wcg/data2/fio_test2.log

Actual results:
bandwidth: 776MB/s  vs  768MB/s


Expected results:
bandwidth: 500MB/s  vs  1000MB/s

Additional info:
blkio.bfq.weight in cgroup-v1 does not work as expected too.
Comment 1 Joseph Qi alibaba_cloud_group 2022-10-14 17:43:18 UTC
Hi, as we discussed in mail list, why not use iocost instead, which is a recommended io weight control solution.
Comment 2 Joseph Qi alibaba_cloud_group 2022-10-14 17:47:56 UTC
BTW, in you test, it seems the results are observed through fio? If so, that's not a right way.
As of now, buffered write io control happens on block layer, that means you have to observe the results from block layer statistics, e.g. cgroup stats. While fio returns the bandwidth of writing page cache.
Comment 3 chuanguo 2022-10-14 18:09:00 UTC
hi josephqi,
  IOCOST could reach my goal.
  This BUGreport is just for doubt at bfq.weigth.
  And So set the improtance to S3-normal.

  By the way, observation, the bps of the two Cgroups I get by reading the 'io.stat' file once a second and calculating the difference are still the same almost.I have no idea about how to observe the bfq.weight effect.
@
Comment 4 Joseph Qi alibaba_cloud_group 2022-10-14 18:48:38 UTC
(In reply to chuanguo from comment #3)
> hi josephqi,
>   IOCOST could reach my goal.
>   This BUGreport is just for doubt at bfq.weigth.
>   And So set the improtance to S3-normal.
> 
>   By the way, observation, the bps of the two Cgroups I get by reading the
> 'io.stat' file once a second and calculating the difference are still the
> same almost.I have no idea about how to observe the bfq.weight effect.
> @

Got it, will take a look.
Comment 5 Joseph Qi alibaba_cloud_group 2022-10-19 17:34:54 UTC
In my test env, for direct io, it works well. But it seems doesn't work for buffered io (writeback).
I've checked the stats from io.stat (cgroup v2) or blkio.bfq.io_service_bytes (cgroup v1).
Since bfq has no real use cases, will dig it deep later.