Stefan- Thanks for the hand-holding, it looks like the disk file is indeed open with O_DIRECT: [root@host ~]# grep ^flags: /proc/$PID/fdinfo/$FD flags: 02140002 Since this is not an issue, I guess another source of problems could be that all the virtio threads attached to this domain are not being placed within the cgroup. I will look through libvirt to see if they're setting the guest's process's cgroup classification as sticky (I can't imagine they wouldn't be), but this raises another question: are virtio kernel threads child processes of the guest's main process? Are you aware of any other factor which I should be considering here? I reran the dd tests inside the guest with iflag=fullblock set to make sure the guest buffer cache wasn't messing with throughput values (based on this: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=5929322cc b1f9d27c1b07b746d37419d17a7cbf6), and got the same results listed earlier. Thanks again! Ben Clay rbclay@xxxxxxxx -----Original Message----- From: Stefan Hajnoczi [mailto:stefanha@xxxxxxxxx] Sent: Tuesday, October 23, 2012 6:35 AM To: Ben Clay Cc: kvm@xxxxxxxxxxxxxxx Subject: Re: FW: cgroup blkio.weight working, but not for KVM guests On Mon, Oct 22, 2012 at 07:36:34AM -0600, Ben Clay wrote: > Forwarding this to the KVM general list. I doubt you folks can help > me with libvirt, but I was wondering if there?s some way to verify if > the cache=none parameter is being respected for my KVM guest?s disk > image, or if there are any other configuration/debug steps appropriate for KVM + virtio + cgroup. Here's how you can double-check the O_DIRECT flag: Find the QEMU process PID on the host: ps aux | grep qemu Then find the file descriptor of the image file which the QEMU process has open: ls -l /proc/$PID/fd Finally look at the file descriptor flags to confirm it is O_DIRECT: grep ^flags: /proc/$PID/fdinfo/$FD Note the flags field is in octal and you're looking for: #define O_DIRECT 00040000 /* direct disk access hint */ Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
