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

Avi Kivity
2008-03-05T06:44:05Z

Anthony Liguori wrote:
> Glauber Costa wrote:
>
>> Anthony Liguori wrote:
>>
>> No, it can't. Because at the time qemu starts, no vcpu -> thread id
>> relationship exists at all. And we don't know when it will.
>>
>
> Sure we do. The vcpu -> thread id relationship is valid after
> kvm_init_ap() is called which is after machine init but before the
> select loop is entered for the first time. Therefore, if you start qemu
> with -S, then connect on the monitor, and do an info cpus, you could be
> guaranteed to be told the mapping.
>
> The threads are *idle* at this point so there's no harm if they were
> started on the "wrong" CPU. You can now taskset to your hearts content
> and then when you're happy with placement, you can issue a 'cont' so
> that the VM actually starts running. I saw "wrong" because you can
> still taskset the initial creation guaranteeing that the threads are
> created on the right group of physical CPUs, you just can't specify the
> exact mapping until you start interacting with the monitor.
>
>

Good points. Initially I thought we ought to abstract the
implementation and not expose the vcpu thread id, but I'm beginning to
thing that due the wide variety of options (affinity, page migration,
priority, cpu control groups) and the relative obscurity of the feature
(which as you point out, isn't needed in the common case), we can export
the thread id and let the management tools deal with it directly.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.