Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2218475ybb; Thu, 2 Apr 2020 15:48:17 -0700 (PDT) X-Google-Smtp-Source: APiQypL+Z7lkmd/EsHgWvmUKWevzN9GPDBwviwGJ5w96RzK1KkcAV5A3+yXUqchZwY7KziGzJToo X-Received: by 2002:a9d:644:: with SMTP id 62mr3762353otn.177.1585867697857; Thu, 02 Apr 2020 15:48:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585867697; cv=none; d=google.com; s=arc-20160816; b=GjovXJhEn945qK7j8BunKYFgOI++tydwiabrbFDgiPr2VDp0lx3Emi7IP6yp7wPE9D toZUBydz6vjchG5DajyFhzBF6PMk0iAtvqLhp8S3bsQqcsf/kSfkr0dB+Sv6YQIBsSeq rhkesYAY27YyJhEM4CHD1CWQaZxClogQxCV+ybXzcz3b8Ev4Sc2LVrYvaKWdc4sJEYYo bB6++P4tnG4aGJdOD4W+koaydy4AfEYAQF1gVexkYW1sPFZmgkiZlV7RVQdH7BQL+n4j 4RA7keH1yK40FqJjOgk21Xs0fCrf/brgVIkKz4JUE6lOsyLfoMrsKW0C/NhdOZsRQm6j icPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=OQnxweQnqXfPXtvAjWkG4LAwMm7QgxQOU06/1lbhuSY=; b=Y0KaeCc1cS3MN9E5eq7NH+Z+y+ABnXa2m5Y1H2FLzG9azAi+0Hj7Bto9BvGMSNFuLP 4g/3aRfGTqdg8Li12sD+QEtZjpwy5zaDm0OsLalcx4UwpyNeq8FFL+0HtYIICzxcrq3L egwfCdUpU/ES1nIV0VPy6XniyuX/cUeL3cKExBXB8uh43b9mc8cHY/RGec/bWG+hmpfh tN6Ctpj/1aJGEYyCtEkt0ALw9FQMrVmcJZ69+OEAIkdhP2PswKcJDPofn8aCcDmLdZRr JpZmjARGQAS0aTU3RZIC3WisZWWrj/Z/Qso+qxcfGB4wMxq5/HAb0eqbNsfAXFwN311X b49g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qYPyZxkk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n10si2807302otk.171.2020.04.02.15.48.04; Thu, 02 Apr 2020 15:48:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qYPyZxkk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389821AbgDBWq5 (ORCPT + 99 others); Thu, 2 Apr 2020 18:46:57 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:34989 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387919AbgDBWq4 (ORCPT ); Thu, 2 Apr 2020 18:46:56 -0400 Received: by mail-io1-f68.google.com with SMTP id o3so5532157ioh.2 for ; Thu, 02 Apr 2020 15:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OQnxweQnqXfPXtvAjWkG4LAwMm7QgxQOU06/1lbhuSY=; b=qYPyZxkk8z01LGWskSrm9aG/7nt3J+cgEH/SymGNN597NCfm6MCdZIy6TzISZy66q4 pj6rRU04jWHnuCETpqmyHTLKqZiwVuEyeFh5Rr0b3hSMwg5eGng2Ha2xdSdKsvmQxAOB QPSasGKfa8n/l/zHMpnSI/pAoBE+Rpko2nlur98dOVL1Ua5pOL9Ld4KHgbshpQDQcTna ZN9LC+pER0Nd3/NjtUkjv0UtAskAfOkP49pxmJi+E9xuTviSHaZd0wPMgN1pFs3Uk30N wghTmqvUOM9XnmeCBS/2N/NZZe5q7C6DI1LgBPQnuYA89x4cjlENgCSO+fUrkfhakK+1 XFEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OQnxweQnqXfPXtvAjWkG4LAwMm7QgxQOU06/1lbhuSY=; b=uIDwbEdLwtKQX2Qin9347d/5MkIlPeLiCPgNcR1jghNZTWLPI4c/Ru2oz39fXhrEzS 5ICsEGhp/BHf7BUmIxtSu87xUESWuxNv3qSNmnb0eC2c2Bx6yYIgIbRur3j+bnpVko2t LBTVJtMxq0uhFVRdR97bccq5Ft3D7eYo93hxHD3I5H8rXxO7//Mp69JmvJ7gsMgM58Bz 4cyz8P8GKvPjWgoQKiJJbZzFbGA4AATKCYPlYcBzm5LP0vfRAq320plu6ojUimLP8aou R3BniDuLJGeZTXtrA2JQt4YYVpyTXSgkpv1mO++NSXQpCFo95Vr6csVNeMynmUDUYAdE dWOQ== X-Gm-Message-State: AGi0Pub3JE7StPeanodflAOMAY463q3kP2R74A19NGryL+AOPN3GElZD CqrAtZI1SNxgvaEkCX9q5VozVnNM0dg2+7iGxpleqlNTnzo= X-Received: by 2002:a05:6638:d6:: with SMTP id w22mr494171jao.72.1585867615842; Thu, 02 Apr 2020 15:46:55 -0700 (PDT) MIME-Version: 1.0 References: <20200402195156.626430-1-leonardo@linux.ibm.com> In-Reply-To: <20200402195156.626430-1-leonardo@linux.ibm.com> From: "Oliver O'Halloran" Date: Fri, 3 Apr 2020 09:46:44 +1100 Message-ID: Subject: Re: [PATCH v3 1/1] powerpc/kernel: Enables memory hot-remove after reboot on pseries guests To: Leonardo Bras Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Nathan Fontenot , Greg Kroah-Hartman , Allison Randal , Bharata B Rao , Claudio Carvalho , Hari Bathini , linuxppc-dev , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 3, 2020 at 6:55 AM Leonardo Bras wrote: > > While providing guests, it's desirable to resize it's memory on demand. > > By now, it's possible to do so by creating a guest with a small base > memory, hot-plugging all the rest, and using 'movable_node' kernel > command-line parameter, which puts all hot-plugged memory in > ZONE_MOVABLE, allowing it to be removed whenever needed. > > But there is an issue regarding guest reboot: > If memory is hot-plugged, and then the guest is rebooted, all hot-plugged > memory goes to ZONE_NORMAL, which offers no guaranteed hot-removal. > It usually prevents this memory to be hot-removed from the guest. > > It's possible to use device-tree information to fix that behavior, as > it stores flags for LMB ranges on ibm,dynamic-memory-vN. > It involves marking each memblock with the correct flags as hotpluggable > memory, which mm/memblock.c puts in ZONE_MOVABLE during boot if > 'movable_node' is passed. I don't really understand why the flag is needed at all. According to PAPR any memory provided by dynamic reconfiguration can be hot-removed so why aren't we treating all DR memory as hot removable? The only memory guaranteed to be there 100% of the time is what's in the /memory@0 node since that's supposed to cover the real mode area.