On Wed, May 28, 2008 at 08:13:44AM -0600, David S. Ahern wrote: > Weird. Could it be something about the hosts?
Note that the VM itself will never make use of kmap. The VM is "data" agonistic. The VM has never any idea with the data contained by the pages. kmap/kmap_atomic/kunmap_atomic are only need to access _data_. Only I/O (if not using DMA, or because of bounce buffers) and page faults triggered in user process context, or other operations again done from user process context will call into kmap or kmap_atomic. And if KVM is inefficient in handling kmap/kmap_atomic that will lead to the user process running slower, and in turn generating less pressure to the guest and host VM if something. Guest will run slower than it should if KVM isn't optimized for the workload but it shouldn't alter any VM kernel thread CPU usage, only the CPU usage of the guest process context and host system time in qemu task should go up, nothing else. This is again because the VM will never care about the data contents and it'll never invoked kmap/kmap_atomic. So I never found a relation to the symptom reported of VM kernel threads going weird, with KVM optimal handling of kmap ptes. -- 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
