On Tue, Oct 23, 2012 at 04:48:13PM -0600, Ben Clay wrote: > 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?
Virtio kernel threads? Depend on the qemu-kvm -drive ...,aio=native|threads setting you should either see: 1. For aio=native QEMU uses the Linux AIO API. I think this results in kernel threads that process I/O on behalf of the userspace process. 2. For aio=threads QEMU uses its own userspace threadpool to call preadv(2)/pwritev(2). These threads are spawned from QEMU's "iothread" event loop. I suggest you try switching between aio=native and aio=threads to check if this causes the result you have been seeing. > Are you aware of any other factor which I should be considering here? No, but I haven't played with the cgroups blkio controller much. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
