From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <5486494C.8060706@cn.fujitsu.com> References: <1409197002-9498-1-git-send-email-guz.fnst@cn.fujitsu.com> <1409197002-9498-11-git-send-email-guz.fnst@cn.fujitsu.com> <54857D61.4030502@cn.fujitsu.com> <20141208163815.40bcb9e2@nial.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Igor Mammedov , "qemu-devel@nongnu.org" , , , Bharata B Rao , ChenFan , Anshul Makkar , "afaerber@suse.de" , Gleb Natapov , kvm To: Peter Maydell Return-path: Received: from cn.fujitsu.com ([59.151.112.132]:33455 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753182AbaLIBOj (ORCPT ); Mon, 8 Dec 2014 20:14:39 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: +cc Gleb, KVM guys, On 12/09/2014 12:38 AM, Peter Maydell wrote: > On 8 December 2014 at 15:38, Igor Mammedov wrote: >> On Mon, 8 Dec 2014 10:50:21 +0000 >> Peter Maydell 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 > . > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy9O2-0001b4-23 for qemu-devel@nongnu.org; Mon, 08 Dec 2014 20:14:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xy9Nx-0007l9-Hk for qemu-devel@nongnu.org; Mon, 08 Dec 2014 20:14:45 -0500 Received: from [59.151.112.132] (port=38984 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy9Nw-0007kY-V2 for qemu-devel@nongnu.org; Mon, 08 Dec 2014 20:14:41 -0500 Message-ID: <5486494C.8060706@cn.fujitsu.com> Date: Tue, 9 Dec 2014 08:58:52 +0800 From: Gu Zheng MIME-Version: 1.0 References: <1409197002-9498-1-git-send-email-guz.fnst@cn.fujitsu.com> <1409197002-9498-11-git-send-email-guz.fnst@cn.fujitsu.com> <54857D61.4030502@cn.fujitsu.com> <20141208163815.40bcb9e2@nial.usersys.redhat.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC V2 10/10] cpus: reclaim allocated vCPU objects List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: kvm , Gleb Natapov , "qemu-devel@nongnu.org" , tangchen@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, Bharata B Rao , ChenFan , Igor Mammedov , Anshul Makkar , "afaerber@suse.de" +cc Gleb, KVM guys, On 12/09/2014 12:38 AM, Peter Maydell wrote: > On 8 December 2014 at 15:38, Igor Mammedov wrote: >> On Mon, 8 Dec 2014 10:50:21 +0000 >> Peter Maydell 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 > . >