On 25.04.2016 20:53, Himadri Sarkar wrote: > Hi, > > I was doing some experiments to test out blkio with the following > setups and was unable to get the expected behavior. It will be great > if someone can help me understand what might have gone wrong with my > setup. > > Setup 1 > hardware: d2.xlarge machine on aws (It has 3 * 2 TB hdd) > logical volume: setup an lvm to use 2 disks out of 3 > file system: xfs > IO Scheduler: cfq > blkio weights: test1 has weight 1000, test2 has weight 500 > > Now when I run the tests as given in > https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt > using dd (I only executed read tests on already written files) > I found that both the processes were getting equal time share > (blkio.time) and serviced bytes (blkio.io_service_bytes) irrespective > of differential weights. > > Now when I modified the setup by not having lvm setup and just > creating a 2TB file system out of a single hdd it worked i.e. serviced > bytes were in the ratio 2 : 1 > > On the other hand when I tested read with fio > > specifically > > fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 > --name=test2 --filename=file2 --bs=4k --iodepth=64 --size=4G > --readwrite=randrw --rwmixread=100 > > Then also it worked even with the lvm setup. Which makes be believe > that with Setup 1 it is not working due to buffered reads. (But then > the same thing also worked without lvm) This is a well-known limitation to LVM, which supposedly was fixed in a recent kernel. For more information check this email thread: https://www.redhat.com/archives/dm-devel/2016-February/msg00183.html Then a patch was proposed in the following thread: https://www.redhat.com/archives/dm-devel/2016-March/msg00006.html This was tested by me and the proportional-based limits were working, provided that the devices hosting the LVM VG were using CFQ as their io scheduler. Regards, Nikolay -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
