qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC V2 10/10] cpus: reclaim allocated vCPU objects


From: Gu Zheng
Subject: Re: [Qemu-devel] [RFC V2 10/10] cpus: reclaim allocated vCPU objects
Date: Tue, 9 Dec 2014 08:58:52 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

+cc Gleb, KVM guys,

On 12/09/2014 12:38 AM, Peter Maydell wrote:

> On 8 December 2014 at 15:38, Igor Mammedov <address@hidden> wrote:
>> On Mon, 8 Dec 2014 10:50:21 +0000
>> Peter Maydell <address@hidden> wrote:
>>> Why can't the kernel handle our just destroying the vcpu and
>>> later recreating it if necessary? That seems the more logical
>>> approach than trying to keep fds hanging around in userspace
>>> for reuse.
>>
>> It's somewhat complex approach and it was suggested on KVM list to go
>> parking route. for more details see thread
>>  https://www.mail-archive.com/address@hidden/msg102839.html
> 
> If the kernel can't cope with userspace creating and destroying
> vCPUs dynamically then that seems like a kernel bug to me.

Yes, it's a flaw.

> It seems better to me to fix that directly rather than make
> non-x86 architectures change things around to help with working
> around that bug...

Agree.
But as we discussed before:
"CPU array is accessed locklessly in a lot of places, so it will have to be 
RCUified. There was attempt to do so 2 year or so ago, but it didn't go 
anyware. 
Adding locks is to big a price to pay for ability to free a little bit
of memory by destroying vcpu."
We worry about the regression if we add lock in a lot of places.
I'm not very familiar with non-x86 architectures. So I'm not sure how long we
need to go to help "vcpu hot-unplug" working with parking route.

Gleb,
Is any guys still working on the RCUing CPUarray access?
Is there any plan for this issue, or just leave it as it is?

Thanks,
Gu

> 
> thanks
> -- PMM
> .
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]