Re: [PATCH 0/8] RFC: vcpu pinning at qemu start

[Anthony Liguori <anthony@codemonkey.ws>]

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.

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.

Regards,

Anthony Liguori

>
>


-------------------------------------------------------------------------
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/