From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ABF2C47095 for ; Wed, 9 Jun 2021 07:45:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EE08261364 for ; Wed, 9 Jun 2021 07:45:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE08261364 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 23C7A6B0036; Wed, 9 Jun 2021 03:45:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EBFE6B006E; Wed, 9 Jun 2021 03:45:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08E0B6B0070; Wed, 9 Jun 2021 03:45:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id C920F6B0036 for ; Wed, 9 Jun 2021 03:45:05 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4AF43906F for ; Wed, 9 Jun 2021 07:45:05 +0000 (UTC) X-FDA: 78233399370.24.49B25BB Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP id B34698019357 for ; Wed, 9 Jun 2021 07:45:00 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id E32E76135D; Wed, 9 Jun 2021 07:45:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623224704; bh=y4vZIplvATPwgmAJfnB4IqR2ttWTUCZLbpeJ7+PF/uE=; h=Date:From:To:Subject:From; b=riMrcdX7jO4Cgf0GW73VBryigY15EcUbup0L2xUKdi2dcWGVwQF0FXN+v1sPjmrQD bIr0xZY+5WnJmhtrlFRLp7b9u5wfV4mhTUGl03KaJWKMgxMRoxMlMR5aAKnX6hp6b2 oqsVp7RBud0nmjBrG10wHMy9iyvr0XnbNfAvFkPsnwbv/Acv+CFsYD5jRqwDrH8gYd RPFXp5gNnmR/D5ZaGruWw19tAFO1G8Hgr2brmettSajwOIDjbw9CtOxSBM8btqNMdT IeilaDzIT5GOKWLbXOQvixP7vSRphIkx65tmJw3sE+1QOFI5dM0brCbgnqOMOZN60t ocGV5CtdRgLVQ== Date: Wed, 9 Jun 2021 10:44:57 +0300 From: Mike Rapoport To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Subject: [LSF/MM/BPF TOPIC] Consolidating representations of the physical memory Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=riMrcdX7; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B34698019357 X-Stat-Signature: 311ych4ox5zd584srbhjd3kks93ma9nu X-HE-Tag: 1623224700-80107 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: We have several coarse representations of the physical memory consisting of [start, end, flags] structures per memory region. There is memblock that some architectures keep after boot, there is iomem_resource tree and "System RAM" nodes in that tree, there are memory blocks exposed in sysfs and then there are per-architecture structures, sometimes even several per architecture. The multiplication of such structures and lack of consistency between some of them does not help the maintainability and can be a reason for subtle bugs here and there. The layout of the physical memory is defined by hardware and firmware and there is not much room for its interpretation; single abstraction of the physical memory should suffice and a single [start, end, flags] type should be enough. There is no fundamental reason why we cannot converge per-architecture representations of the physical memory, like e820, drmem_lmb, memblock or numa_meminfo into a generic abstraction. I suggest to use memblock as the basis for such abstraction. It is already supported on all architectures and it is used as the generic representation of the physical memory at boot time. Closing the gaps between per architecture structures and memblock is anyway required for more robust initialization of the memory management. Addition of simple locking of memblock data for memory hotplug, making the memblock "allocator" part discardable and a mechanism to synchronize "System RAM" resources with memblock would complete the picture. -- Sincerely yours, Mike.