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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8F1EC433EF for ; Tue, 1 Feb 2022 19:06:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B8EC8D0080; Tue, 1 Feb 2022 14:06:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 240888D006D; Tue, 1 Feb 2022 14:06:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 108338D0080; Tue, 1 Feb 2022 14:06:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id 033168D006D for ; Tue, 1 Feb 2022 14:06:39 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B6E9E18265288 for ; Tue, 1 Feb 2022 19:06:38 +0000 (UTC) X-FDA: 79095142476.28.BC2BB10 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 3095E1C0002 for ; Tue, 1 Feb 2022 19:06:37 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 38F90615F7; Tue, 1 Feb 2022 19:06:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44F6DC340EB; Tue, 1 Feb 2022 19:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643742396; bh=K4vqpRPLUCSYI+AU1QZtOQnmKDQg9M3ZHsEGul4YZds=; h=Date:From:To:Subject:From; b=nY0vQH2+7UdEPF/JLUtpdQtTH23XtCTzjYkpiTLieEJ/HE1CJPEqsCiTCngo62+TR H14EhO6F8T/qt9L8/AM66WQFOykPH+vskDFvrhaxz2WmUgVIZXqgOvTkX2lebupXgQ vLyWmbJPdnP76Yg3h0wJN4hu9kWsoY/dP5YiZRE+exx4QTkB/sXUqRkEN6Fn+GgLtg x9sbDV3abtrQXeCJg5fRkUp/+gn4emk1fFC98x3eej1kDwhY738LBZ9P/26rKJvtje 8EYNa7HlVItdwe64eddbtvK4aey0H+bOtwjfJgBl0XvcowlUp8O4L5lc458c/qvS/j HCns/N6gcyoiA== Date: Tue, 1 Feb 2022 21:06:29 +0200 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 X-Rspam-User: nil X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3095E1C0002 X-Stat-Signature: 83wjgfn5icje7qeqimyid5jpi8ziitx4 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nY0vQH2+; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1643742397-25059 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: Hi all, I've posted this last year, but last year was a bit slow for me, so nothing really changed since then :( 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.