From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: kvm <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
tangchen@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
Bharata B Rao <bharata.rao@gmail.com>,
ChenFan <chen.fan.fnst@cn.fujitsu.com>,
Igor Mammedov <imammedo@redhat.com>,
Anshul Makkar <anshul.makkar@profitbricks.com>,
"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC V2 10/10] cpus: reclaim allocated vCPU objects
Date: Tue, 9 Dec 2014 08:58:52 +0800 [thread overview]
Message-ID: <5486494C.8060706@cn.fujitsu.com> (raw)
In-Reply-To: <CAFEAcA8cRDc7JYA1Q61GwT3x9HUFmLQ70WO---S9naMZ9JzfFw@mail.gmail.com>
+cc Gleb, KVM guys,
On 12/09/2014 12:38 AM, Peter Maydell wrote:
> On 8 December 2014 at 15:38, Igor Mammedov <imammedo@redhat.com> wrote:
>> On Mon, 8 Dec 2014 10:50:21 +0000
>> Peter Maydell <peter.maydell@linaro.org> 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/kvm@vger.kernel.org/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
> .
>
next prev parent reply other threads:[~2014-12-09 1:14 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-28 3:36 [Qemu-devel] [RFC V2 00/10] cpu: add device_add foo-x86_64-cpu and i386 cpu hot remove support Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 01/10] cpu: introduce CpuTopoInfo structure for argument simplification Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 02/10] qom/cpu: move register_vmstate to common CPUClass.realizefn Gu Zheng
2014-09-09 12:17 ` Igor Mammedov
2014-09-10 2:38 ` Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 03/10] cpu: add device_add foo-x86_64-cpu support Gu Zheng
2014-09-09 12:44 ` Igor Mammedov
2014-09-10 3:37 ` Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 04/10] x86: add x86_cpu_unrealizefn() for cpu apic remove Gu Zheng
2014-09-09 13:58 ` Igor Mammedov
2014-09-11 3:06 ` Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 05/10] i386: add cpu device_del support Gu Zheng
2014-09-09 14:11 ` Igor Mammedov
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 06/10] qom cpu: rename variable 'cpu_added_notifier' to 'cpu_hotplug_notifier' Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 07/10] qom cpu: add UNPLUG cpu notify support Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 08/10] i386: implement pc interface cpu_common_unrealizefn() in qom/cpu.c Gu Zheng
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 09/10] cpu hotplug: implement function cpu_status_write() for vcpu ejection Gu Zheng
2014-09-09 14:28 ` Igor Mammedov
2014-08-28 3:36 ` [Qemu-devel] [RFC V2 10/10] cpus: reclaim allocated vCPU objects Gu Zheng
2014-09-09 14:40 ` Igor Mammedov
2014-09-10 3:54 ` Gu Zheng
2014-09-11 9:35 ` Bharata B Rao
2014-09-11 9:49 ` Gu Zheng
2014-09-11 9:53 ` Gu Zheng
2014-09-11 12:37 ` Bharata B Rao
2014-09-12 1:24 ` Gu Zheng
2014-09-12 8:09 ` Bharata B Rao
2014-09-12 9:53 ` Gu Zheng
2014-09-12 10:30 ` Bharata B Rao
2014-09-12 10:53 ` Anshul Makkar
2014-09-12 13:52 ` Bharata B Rao
2014-09-12 15:34 ` Anshul Makkar
2014-09-15 6:39 ` Gu Zheng
2014-09-15 10:09 ` Bharata B Rao
2014-09-15 10:33 ` Anshul Makkar
2014-09-15 13:53 ` Bharata B Rao
2014-09-15 14:29 ` Anshul Makkar
2014-09-11 10:03 ` Anshul Makkar
2014-09-12 14:15 ` Igor Mammedov
2014-09-15 5:03 ` Gu Zheng
2014-12-08 9:16 ` Bharata B Rao
2014-12-08 9:26 ` Peter Maydell
2014-12-08 10:28 ` Gu Zheng
2014-12-08 10:50 ` Peter Maydell
2014-12-08 15:38 ` Igor Mammedov
2014-12-08 16:38 ` Peter Maydell
2014-12-09 0:58 ` Gu Zheng [this message]
2014-12-08 10:12 ` Gu Zheng
2014-11-12 1:46 ` [Qemu-devel] [RFC V2 00/10] cpu: add device_add foo-x86_64-cpu and i386 cpu hot remove support Gu Zheng
2014-11-12 1:46 ` Gu Zheng
2014-11-12 7:57 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5486494C.8060706@cn.fujitsu.com \
--to=guz.fnst@cn.fujitsu.com \
--cc=afaerber@suse.de \
--cc=anshul.makkar@profitbricks.com \
--cc=bharata.rao@gmail.com \
--cc=chen.fan.fnst@cn.fujitsu.com \
--cc=gleb@redhat.com \
--cc=imammedo@redhat.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kvm@vger.kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=tangchen@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).