From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6X4-0002Nn-H1 for qemu-devel@nongnu.org; Thu, 24 Mar 2016 10:46:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj6Wy-0003kh-Co for qemu-devel@nongnu.org; Thu, 24 Mar 2016 10:46:42 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:46944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6Wy-0003kb-5D for qemu-devel@nongnu.org; Thu, 24 Mar 2016 10:46:36 -0400 Received: from localhost by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 24 Mar 2016 08:22:10 -0600 References: <1458016736-10544-1-git-send-email-bharata@linux.vnet.ibm.com> <1458016736-10544-3-git-send-email-bharata@linux.vnet.ibm.com> <20160316013605.GC9032@voom> <20160316044154.GD13176@in.ibm.com> <20160323032230.GU23586@voom.redhat.com> From: Nathan Fontenot Message-ID: <56F3F69E.9090306@linux.vnet.ibm.com> Date: Thu, 24 Mar 2016 09:15:58 -0500 MIME-Version: 1.0 In-Reply-To: <20160323032230.GU23586@voom.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 2/2] spapr: Memory hot-unplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , Bharata B Rao Cc: imammedo@redhat.com, thuth@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com On 03/22/2016 10:22 PM, David Gibson wrote: > On Wed, Mar 16, 2016 at 10:11:54AM +0530, Bharata B Rao wrote: >> On Wed, Mar 16, 2016 at 12:36:05PM +1100, David Gibson wrote: >>> On Tue, Mar 15, 2016 at 10:08:56AM +0530, Bharata B Rao wrote: >>>> Add support to hot remove pc-dimm memory devices. >>>> >>>> Signed-off-by: Bharata B Rao >>> >>> Reviewed-by: David Gibson >>> >>> Looks correct, but again, needs to wait on the PAPR change. >>> >>> Have you thought any further on the idea of sending an index message, >>> then a count message as an interim approach to fixing this without >>> requiring a PAPR change? >> >> Removal by index and removal by count are valid messages by themselves >> and drmgr would go ahead and start the removal in reponse to those >> calls. IIUC, you are suggesting that lets remove one LMB by index in >> response to 1st message and remove (count -1) LMBs from where the last >> removal was done in the previous message. > > Yes, that's the idea. > >> Since the same code base of powerpc-utils works on PowerVM too, I am not >> sure if such an approach would impact PowerVM in any undesirable manner. >> May be Nathan can clarify ? The issue I see with this approach is that there is no way in the current drmgr code to correlate the two memory remove requests. If I understand what you are asking to do correctly, this would result in two separate invocations of drmgr. The first to remove a specific LMB by index, this index then needing to be saved somewhere, then a second invocation that would retrieve the index and remove count-1 LMBs. Would there be anything tying these two requests together? or would we assume that two requests received in this order are correlated? What happens if another request comes in in between these two requests? I see this as being a pretty rare possibility, but it is a possibility. > > Heard anything from Nathan? I don't really see how it would be bad > under PowerVM. Under PowerVM it generally doesn't matter which LMBs > you remove, right? So removing the ones immediately after the last > one you removed should be as good a choice as any. This shouldn't hurt anything for PowerVM systems. In general the only time a specific LMB is specified for PowerVM systems is on memory guard operations. > >> I see that this can be done, but the changes in drmgr code specially the >> code related to LMB list handling/removal can be non-trivial. So not sure >> if the temporary approach is all that worth here and hence I feel it is better >> to wait and do it the count-indexed way. > > Really? drmgr is already scanning LMBs to find ones it can remove. > Seeding that scan with the last removed LMB shouldn't be too hard. This shouldn't be difficult to implement in the drmgr code. We already search a list of LMBs to find ones to remove, updating to just return the LMB with the next sequential index shouldn't be difficult. -Nathan > >> While we are here, I would also like to get some opinion on the real >> need for memory unplug. Is there anything that memory unplug gives us >> which memory ballooning (shrinking mem via ballooning) can't give ? > > Hmm.. that's an interesting question. >