Daniel P. Berrange wrote: > On Tue, Mar 04, 2008 at 01:28:24PM -0600, Anthony Liguori wrote: >> Glauber Costa wrote: >>> My main interest is in management tools being able to specify pinning >>> set ups at VM creation time. >>> >>> As I said, it can be done through tools like taskset, but then you'd >>> have to know: >>> * when are the threads created >>> * which thread ids corresponds to each cpu >>> >>> And of course, for an amount of time, the threads will be running in a >>> "wrong" cpu, which may affect workloads running there. (which is a >>> case cpu pinning usually tries to address) >> A management tool can start QEMU with -S to prevent any CPUs from >> running, query the VCPU=>thread id relationship (modifying info cpus >> would be a good thing to do for this), taskset, and then run 'cont' in >> the monitor if they desperately need this functionality. However, I >> don't think the vast majority of people need this particular functionality. > > I fully expected to have to run QEMU with -S and then use cont if I were > todo CPU pinning from libvirt. > > The only info I'd need to get is the PID <-> vCPU mapping data. Then > I can use regular Linux taskset capabilities from libvirt to assign the > initial pCPU <-> vCPU mapping and finally run 'cont'. > >> My feeling is that adding an interface to do this in QEMU encourages >> people to not use the existing Linux tools for this or worse yet, to >> think they can do a better job than Linux. The whole reason this exists >> in Xen is that Xen's schedulers were incapable of doing CPU migration >> historically (which is no longer true since the credit scheduler). It >> was necessary to specify pinning upon creation or you were stuck with >> round-robin placement. So libvirt has APIs for this because they were >> part of the Xen API because it was needed to get reasonable performance >> at some point in time on Xen. I don't think this behavior is useful for >> KVM though. Just because Xen does it doesn't imply that we should do it. > > I agree that adding QEMU commands for stuff which Linux already has APIs > and tools is a bad idea. QEMU/KVM is much nicer to manage than Xen, > precisely because I can already use Linux APIs & process management tools.
I totally agree this is ideal, and I did not start this after thinking a little bit about this situation. The main point is that we don't know when the cpus are created, and it does not seem to me that we will without a considerable amount of work. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
