Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1743480pxu; Fri, 16 Oct 2020 23:00:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSGhEuGI9jj16tp3JYYJskmb34wT+rsBiATjgCKutwjkxMIXV9s73KrHHat16Y/CRTdqDU X-Received: by 2002:a17:906:95c5:: with SMTP id n5mr7508728ejy.111.1602914418308; Fri, 16 Oct 2020 23:00:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602914418; cv=none; d=google.com; s=arc-20160816; b=QxGlwyX1HMv6TOnBgh364GSFO7HtFzsSeiehRTPI3UBowpjVTetF/J3XmV1cxb5tJo wb6c+GzDS2WPxVsqReMDkhslwqqtxA//Suynr9SlPWQYS3D0ELU09NAIhyZKY75RnFgu EmOp7VRR5od6bmXcnr1C7KxRmzM2201Zn2YMVt3d91OkMOBZ6NRyvfSxDcpff9xK60LH MkmkbnwB09LNVINBXwTe+i4/iakWDqf7cFDYgcwNKzFrtUWvK5fXcDDQ61biGtOP8mVU 4uw+75ovbyZShslLpQlUZiAW5aJjY0hkwqNTueYiFbE0m6tqWMiBIxo7AHz3vxnXlLmF Bm6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dmarc-filter:sender :dkim-signature; bh=O39GHa5Zc7YYi6xk0MgUGMyJ7D1ZYO+P8ngBtf0mzWU=; b=y91OzWQK32tgeaPfAU5oNmNqWned3gDLgQm4OXO+fBXYeY6fzSovLIZKg69f2iHvHS SoX1+WG+00JwoBWpdTbXavcN7EgtcWeXXVpn9yWHMhd76rihf5TvW/o9jZEPZsEsJE4C sRNp0Wc1ZgoNtiSKnyMK0oS1pmO253jM6BKrLXA0naeRKX/mNec2aXe3jfOIGcYmuMFt 04fy1PLr2Vwg8aVZGICAIBltoa0jvZ1JRkicDhzaRdf2+SXR0rZdW7BDos8p6apX6m1v zSmxcAQsMG/YQzeCafeoUg8gEvkPxGqH867rHbvQj27OnBzr9g1MSMOI17AGwhmnI5XM wyUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=LPaxnwnW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n24si3363069ejz.503.2020.10.16.22.59.55; Fri, 16 Oct 2020 23:00:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=LPaxnwnW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2436780AbgJQF6O (ORCPT + 99 others); Sat, 17 Oct 2020 01:58:14 -0400 Received: from z5.mailgun.us ([104.130.96.5]:19564 "EHLO z5.mailgun.us" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436763AbgJQF6O (ORCPT ); Sat, 17 Oct 2020 01:58:14 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1602914294; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-Id: Date: Subject: Cc: To: From: Sender; bh=O39GHa5Zc7YYi6xk0MgUGMyJ7D1ZYO+P8ngBtf0mzWU=; b=LPaxnwnW+8p7cau0WW5/01YfetRb5f2berm9wtC5Ip73KmJJ4fuDh7fOj7yyigInGvui6Sad 4KeVeOvEtYyRAYqp6nvU0JBlXc24LpcaRdVl9sPl9tDiLTWNJJKQBgxUzfmVkSilC9y4tHaR YIwGNql69VWeTuql6qi5662PEiY= X-Mailgun-Sending-Ip: 104.130.96.5 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n07.prod.us-east-1.postgun.com with SMTP id 5f8a50c44f8cc67c31616dbc (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Sat, 17 Oct 2020 02:02:44 GMT Sender: sudaraja=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 6ADEEC433CB; Sat, 17 Oct 2020 02:02:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00,SPF_FAIL autolearn=no autolearn_force=no version=3.4.0 Received: from th-lint-014.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sudaraja) by smtp.codeaurora.org (Postfix) with ESMTPSA id A6313C433C9; Sat, 17 Oct 2020 02:02:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A6313C433C9 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=sudaraja@codeaurora.org From: Sudarshan Rajagopalan To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Sudarshan Rajagopalan Subject: [PATCH 0/2] mm/memory_hotplug, arm64: allow certain bootmem sections to be offlinable Date: Fri, 16 Oct 2020 19:02:22 -0700 Message-Id: X-Mailer: git-send-email 2.25.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In the patch that enables memory hot-remove (commit bbd6ec605c0f ("arm64/mm: Enable memory hot remove")) for arm64, there’s a notifier put in place that prevents boot memory from being offlined and removed. The commit text mentions that boot memory on arm64 cannot be removed. But x86 and other archs doesn’t seem to do this prevention. The current logic is that only “new” memory blocks which are hot-added can later be offlined and removed. The memory that system booted up with cannot be offlined and removed. But there could be many usercases such as inter-VM memory sharing where a primary VM could offline and hot-remove a block/section of memory and lend it to secondary VM where it could hot-add it. And after usecase is done, the reverse happens where secondary VM hot-removes and gives it back to primary which can hot-add it back. In such cases, the present logic for arm64 doesn’t allow this hot-remove in primary to happen. Also, on systems with movable zone that sort of guarantees pages to be migrated and isolated so that blocks can be offlined, this logic also defeats the purpose of having a movable zone which system can rely on memory hot-plugging, which say virt-io mem also relies on for fully plugged memory blocks. This patch tries to solve by introducing a new section mem map sit 'SECTION_MARK_HOTPLUGGABLE' which allows the concerned module drivers be able to mark requried sections as "hotpluggable" by setting this bit. Also this marking is only allowed for sections which are in movable zone and have unmovable pages. The arm64 mmu code on receiving the MEM_GOING_OFFLINE notification, we disallow offlining of any boot memory by checking if section_early or not. With the introduction of SECTION_MARK_HOTPLUGGABLE, we allow boot mem sections that are marked as hotpluggable with this bit set to be offlined and removed. Thereby allowing required bootmem sections to be offlinable. Sudarshan Rajagopalan (2): mm/memory_hotplug: allow marking of memory sections as hotpluggable arm64: allow hotpluggable sections to be offlined arch/arm64/mm/mmu.c | 2 +- include/linux/memory_hotplug.h | 1 + include/linux/mmzone.h | 9 ++++++++- mm/memory_hotplug.c | 20 ++++++++++++++++++++ mm/sparse.c | 31 +++++++++++++++++++++++++++++++ 5 files changed, 61 insertions(+), 2 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project