Avi Kivity wrote:
> I estimate that that take_cpu_down will run for about a millisecond if
> there are a few hundred vcpus which have last run on the dying cpu (and
> that's an extreme case, which is not expected in normal operation).
I measured vmclear time on an uncached vmcs (which would be all
Shaohua Li wrote:
> On Thu, 2007-05-24 at 20:10 +0800, Avi Kivity wrote:
>
>> The following patchset makes kvm more robust wrt cpu hotunplug, and
>> makes suspend-to-ram actually work. Suspend-to-disk benefits from
>> the cpu hotunplug improvements as well.
>>
>> The major issue is that KVM wan
On Thu, 2007-05-24 at 20:10 +0800, Avi Kivity wrote:
> The following patchset makes kvm more robust wrt cpu hotunplug, and
> makes suspend-to-ram actually work. Suspend-to-disk benefits from
> the cpu hotunplug improvements as well.
>
> The major issue is that KVM wants to disable the virtualizat
Avi Kivity wrote:
> The following patchset makes kvm more robust wrt cpu hotunplug, and
> makes suspend-to-ram actually work. Suspend-to-disk benefits from
> the cpu hotunplug improvements as well.
>
>
Here's the patchset diffstat in case anyone's interested:
arch/i386/kernel/cpu/mcheck/ther
The following patchset makes kvm more robust wrt cpu hotunplug, and
makes suspend-to-ram actually work. Suspend-to-disk benefits from
the cpu hotunplug improvements as well.
The major issue is that KVM wants to disable the virtualization
extensions at a point in time when no user processes are sc
