On Fri, 8 Apr 2016 14:55:29 +0200 Pradeep Kiruvale <pradeepkiruv...@gmail.com> wrote:
> Hi Greg, > > FInd my replies inline > > > > > > Below is the way how I add to blkio > > > > > > echo "8:16 8388608" > > > > /sys/fs/cgroup/blkio/test/blkio.throttle.write_bps_device > > > > > > > Ok, this just puts a limit of 8MB/s when writing to /dev/sdb for all > > tasks in the test cgroup... but what about the tasks themselves ? > > > > > The problem I guess is adding these task ids to the "tasks" file in > > cgroup > > > > > > > Exactly. :) > > > > > These threads are started randomly and even then I add the PIDs to the > > > tasks file the cgroup still does not do IO control. > > > > > > > How did you get the PIDs ? Are you sure these threads you have added to the > > cgroup are the ones that write to /dev/sdb ? > > > > *Yes, I get PIDs from /proc/Qemu_PID/task* > And then you echoed the PIDs to /sys/fs/cgroup/blkio/test/tasks ? This is racy... another IO thread may be started to do some work on /dev/sdb just after you've read PIDs from /proc/Qemu_PID/task, and it won't be part of the cgroup. > > > > > > > Is it possible to reduce these number of threads? I see different number > > of > > > threads doing IO at different runs. > > > > > > > AFAIK, no. > > > > Why don't you simply start QEMU in the cgroup ? Unless I miss something, > > all > > children threads, including the 9p ones, will be in the cgroup and honor > > the > > throttle setttings. > > > > > *I started the qemu with cgroup as below* > > *cgexec -g blkio:/test qemu.......* > *Is there any other way of starting the qemu in cgroup?* > Maybe you can pass --sticky to cgexec to prevent cgred from moving children tasks to other cgroups... There's also the old fashion method: # echo $$ > /sys/fs/cgroup/blkio/test/tasks # qemu..... This being said, QEMU is a regular userspace program that is completely cgroup agnostic. It won't behave differently than 'dd if=/dev/sdb of=/dev/null'. This really doesn't look like a QEMU related issue to me. > Regards, > Pradeep > Cheers. -- Greg > > > > > > Regards, > > > Pradeep > > > > > > > Cheers. > > > > -- > > Greg > > > > > > > > On 8 April 2016 at 10:10, Greg Kurz <gk...@linux.vnet.ibm.com> wrote: > > > > > > > On Thu, 7 Apr 2016 11:48:27 +0200 > > > > Pradeep Kiruvale <pradeepkiruv...@gmail.com> wrote: > > > > > > > > > Hi All, > > > > > > > > > > I am using virtio-9p for sharing the file between host and guest. To > > test > > > > > the shared file I do read/write options in the guest.To have > > controlled > > > > io, > > > > > I am using cgroup blkio. > > > > > > > > > > While using cgroup I am facing two issues,Please find the issues > > below. > > > > > > > > > > 1. When I do IO throttling using the cgroup the read throttling works > > > > fine > > > > > but the write throttling does not wok. It still bypasses these > > throttling > > > > > control and does the default, am I missing something here? > > > > > > > > > > > > > Hi, > > > > > > > > Can you provide details on your blkio setup ? > > > > > > > > > I use the following commands to create VM, share the files and to > > > > > read/write from guest. > > > > > > > > > > *Create vm* > > > > > qemu-system-x86_64 -balloon none .......-name vm0 -cpu host -m 128 > > -smp 1 > > > > > -enable-kvm -parallel .... -fsdev > > > > > local,id=sdb1,path=/mnt/sdb1,security_model=none,writeout=immediate > > > > -device > > > > > virtio-9p-pci,fsdev=sdb1,mount_tag=sdb1 > > > > > > > > > > *Mount file* > > > > > mount -t 9p -o trans=virtio,version=9p2000.L sdb1 /sdb1_ext4 > > 2>>dd.log && > > > > > sync > > > > > > > > > > touch /sdb1_ext4/dddrive > > > > > > > > > > *Write test* > > > > > dd if=/dev/zero of=/sdb1_ext4/dddrive bs=4k count=800000 > > oflag=direct >> > > > > > dd.log 2>&1 && sync > > > > > > > > > > *Read test* > > > > > dd if=/sdb1_ext4/dddrive of=/dev/null >> dd.log 2>&1 && sync > > > > > > > > > > 2. The other issue is when I run "dd" command inside guest it > > creates > > > > > multiple threads to write/read. I can see those on host using iotop > > is > > > > this > > > > > expected behavior? > > > > > > > > > > > > > Yes. QEMU uses a thread pool to handle 9p requests. > > > > > > > > > Regards, > > > > > Pradeep > > > > > > > > Cheers. > > > > > > > > -- > > > > Greg > > > > > > > > > > > >