Weiping Zhang <zwp10758@xxxxxxxxx> 于2020年3月26日周四 上午12:45写道： > > Tejun Heo <tj@xxxxxxxxxx> 于2020年3月25日周三 下午10:12写道： > > > > On Wed, Mar 25, 2020 at 08:49:24PM +0800, Weiping Zhang wrote: > > > For this patchset, iotrack can work well, I'm using it to monitor > > > block cgroup for > > > selecting a proper io isolation policy. > > > > Yeah, I get that but monitoring needs tend to diverge quite a bit > > depending on the use cases making detailed monitoring often need fair > > bit of flexibility, so I'm a bit skeptical about adding a fixed > > controller for that. I think a better approach may be implementing > > features which can make dynamic monitoring whether that's through bpf, > > drgn or plain tracepoints easier and more efficient. > > > I agree with you, there are lots of io metrics needed in the real > production system. > The more flexible way is export all bio structure members of bio’s whole life to > the userspace without re-compiling kernel, like what bpf did. > > Now the main block cgroup isolation policy: > blk-iocost and bfq are weght based, blk-iolatency is latency based. > The blk-iotrack can track the real percentage for IOs,kB,on disk time(d2c), > and total time, it’s a good indicator to the real weight. For blk-iolatency, the > blk-iotrack has 8 lantency thresholds to show latency distribution, so if we > change these thresholds around to blk-iolateny.target.latency, we can tune > the target latency to a more proper value. > > blk-iotrack extends the basic io.stat. It just export the important > basic io statistics > for cgroup,like what /prof/diskstats for block device. And it’s easy > programming, > iotrack just working like iostat, but focus on cgroup. > > blk-iotrack is friendly with these block cgroup isolation policies, a > indicator for > cgroup weight and lantency. > Hi Tejun, I do a testing at cgroup v2 and monitoring them by iotrack, then I compare the fio's output and iotrack's, they can match well. cgroup weight test: /sys/fs/cgroup/test1 /sys/fs/cgroup/test2 test1.weight : test2.weight = 8 : 1 Now I just run randread-4K fio test by these three policy: iocost, bfq, and nvme-wrr For blk-iocost I run "iocost_coef_gen.py" and set result to the "io.cost.model". 259:0 ctrl=user model=linear rbps=3286476297 rseqiops=547837 rrandiops=793881 wbps=2001272356 wseqiops=482243 wrandiops=483037 But iocost_test1 cannot get 8/(8+1) iops, and the total disk iops is 737559 < 79388, even I change rrandiops=637000. test case bw iops rd_avg_lat rd_p99_lat ========================================================== iocost_test1 1550478 387619 659.76 1662.00 iocost_test2 1399761 349940 730.83 1712.00 wrr_test1 2618185 654546 390.59 1187.00 wrr_test2 362613 90653 2822.62 4358.00 bfq_test1 714127 178531 1432.43 489.00 bfq_test2 178821 44705 5721.76 552.00 The detail test report can be found at: https://github.com/dublio/iotrack/wiki/cgroup-io-weight-test > Thanks
