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 A9E67C5479D for ; Mon, 9 Jan 2023 14:04:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43DB68E0005; Mon, 9 Jan 2023 09:04:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EE4D8E0003; Mon, 9 Jan 2023 09:04:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B6248E0005; Mon, 9 Jan 2023 09:04:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1B59F8E0003 for ; Mon, 9 Jan 2023 09:04:04 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CF0331608BC for ; Mon, 9 Jan 2023 14:04:03 +0000 (UTC) X-FDA: 80335429566.27.D72AC56 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf11.hostedemail.com (Postfix) with ESMTP id 02F3240011 for ; Mon, 9 Jan 2023 14:04:00 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uPFE8jpo; spf=pass (imf11.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673273041; a=rsa-sha256; cv=none; b=Hbs2MT154tnLZefANZ1mNYYANsfaU8gI5CLF9QxSknlK0PykMfl/wgKHVyZX6hSpvZ8tOZ O78T2+PivGDP2aHJKTqQU6vBWZk52uTqg7QaMNoUVvKEY7trBsfJItPfVr75Nid6VRGZ8J PQ8vdECKyPPakQrOw9/nd5IuS13+Q3g= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uPFE8jpo; spf=pass (imf11.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673273041; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Yytbyq+JQLW801FLeISnLNue6/vE+tpT1aKs9MbNli4=; b=ogS0M+gxrehwqrjeFsNcjup0RGUo4pnt/DG1xYWZeeXfXG1WkyaY+FcfJDGul0VoLtGtRx 8h2pW7TytfP6mA0oeWv76YJaVe0f7OYYppP9XY/INscxX26qoZj+NYb0wowZgEA8CNG4It P0mINhcVroN9w/DI15KJBE7/9bQ2vyM= 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 ams.source.kernel.org (Postfix) with ESMTPS id 53F32B80DDE; Mon, 9 Jan 2023 14:03:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8581C433EF; Mon, 9 Jan 2023 14:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673273038; bh=XDPThGpaR2A08Y5i5XDOoJYueRBv/oUcKLeKgGTtfng=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uPFE8jpoWjguzwsWpnR+NPXoZ8b51wBtY/XhNgkEI8KWdo63mdqVBK4l1+brr9CLk 8v6FqHQIFDrG345qKqDWG0iaDz88bD52HeFnAUO5zzD6H2sON4IJo/yrmWR79Qgxr2 /PP8Z3tZT6E2wez5MhjDUSamEoohDqK2CEseSW4ON2WKgLRRI0mXZDQmuU6NyM68/x mRc/mpICsfRNEqAfc7rp1OakuNMsv8GsI+AyFURQFlXOd75aThAEY4PcDU5Brw6CZo q3GXDSvpf+QfP++Rbl9iaNfLHzbaPjC1c0zXFDLl79efiKEiT7+lV8wajy24gI87l9 4hwjAA8mGKh6Q== Date: Mon, 9 Jan 2023 16:03:43 +0200 From: Mike Rapoport To: Bagas Sanjaya Cc: Jonathan Corbet , Andrew Morton , David Hildenbrand , Johannes Weiner , Lorenzo Stoakes , "Matthew Wilcox (Oracle)" , Mel Gorman , Michal Hocko , Vlastimil Babka , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/2] docs/mm: Physical Memory: add structure, introduction and nodes description Message-ID: References: <20230101094523.1522109-1-rppt@kernel.org> <20230101094523.1522109-3-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 02F3240011 X-Rspamd-Server: rspam01 X-Stat-Signature: suob5oquhmknwbodpfc79dbu3kdwyy5s X-HE-Tag: 1673273040-868439 X-HE-Meta: U2FsdGVkX18kpGUDZnaxAFh9XOiCoEfIXl3zHF5sA4sn/K2pWHy9zt05KaQqLCxhjfbDJbZATV1yF3K2tw82vuMK/KUjMi9K9omj/5dkEGOMbrjo9SAlfmlPVTvpYxnKfkaTJN8otUKOX1WWkiMgvrW6CLmklou9mSdA5GCY3lswT/aPsu/yDdbxs5/ikgbDJNrtwuw7ESA9WcQ/r8Eb38inKmuqPHBAzUdqgYrDAaNvdC2/nWp5k4mwl/2GJBmICQbhFbwek9rfmFJ2iT79xrk6x2wp3EFZhriK3YaSLjCUQFrBbzKNeTnTjqMd/Ras0wcNckQa6IXktgxhY7gXOiEAwd3Q9iKHIUQ5/QHrRmM2qoO7x30FYk4+2TRkNSyfEFW5BJbeC8W1583rscRj8RUnHoH0Oqb3Pycw+iy8NU5e9glubipk9x3XYXykcy3hADGeZbn8AJ5+BECPQ/dpycesNmkO56ExxbQD1Brwoi2PbzCdlKJ5kkmZqWhOoWuRqZbj5TFTx7ivnJSMzpK7d1aFwkpmFgIAu5ikfpyMZ5o5JT5zPbGFLrEOBzOWw80kqfKdUFiZVwYjyanHpcdpL1U4WNtsmbeTSAkqpBMY2I26AXWalP8bp79lajnUTmWxnQ2tyr9s0aNj4rxYs7NTk1hQ0GaN43UZQ3k/kPSGC+V13Uc6QeJS7ouIcEaU2CxfNh+R4PlvGG6/kdBx/92z3oRwCvnydZRFj5B6KdC1VMC63YeWw8cP3H40pnKSRHop+PerIr3sHiv+YYtduEW46VGAsKrCx2pC5e+dm0ipdrqmfAaiJX759RR4HyopXSTMY8Umha6YgCyhnw8EVaWcQRdk1Ov4lk9+6XflxBd2JC/gBwIH63PcbwPzkpz2I8ekSNBxty+fD1zxVegDVLXOmylm5JKgAN9LIYvKw4Z4xA6avxGt0eJmgPsoVywY+StJqFOxrM3b6ysDbUCql78 G/ccSgCg xIariMXcVof7n03MWqF0Ydc1HB9UpwxPd4Coa 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: On Sat, Jan 07, 2023 at 10:55:26AM +0700, Bagas Sanjaya wrote: > On Sun, Jan 01, 2023 at 11:45:23AM +0200, Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > > > No patch description really? The subject says it all, but I can copy it to the description as well. > > +Each node may be divided up into a number of blocks called zones which > > +represent ranges within memory. These ranges are usually determined by > > +architectural constraints for accessing the physical memory. A zone is > > +described by a ``struct zone_struct``, typedeffed to ``zone_t`` and each zone > > +has one of the types described below. > > + > > +`ZONE_DMA` and `ZONE_DMA32` > > + represent memory suitable for DMA by peripheral devices that cannot > > + access all of the addressable memory. Depending on the architecture, > > + either of these zone types or even they both can be disabled at build > > + time using ``CONFIG_ZONE_DMA`` and ``CONFIG_ZONE_DMA32`` configuration > > + options. Some 64-bit platforms may need both zones as they support > > + peripherals with different DMA addressing limitations. > > + > > +`ZONE_NORMAL` > > + is for normal memory that can be accessed by the kernel all the time. DMA > > + operations can be performed on pages in this zone if the DMA devices support > > + transfers to all addressable memory. ZONE_NORMAL is always enabled. > > + > > +`ZONE_HIGHMEM` > > + is the part of the physical memory that is not covered by a permanent mapping > > + in the kernel page tables. The memory in this zone is only accessible to the > > + kernel using temporary mappings. This zone is available only some 32-bit > > + architectures and is enabled with ``CONFIG_HIGHMEM``. > > + > > +`ZONE_MOVABLE` > > + is for normal accessible memory, just like ZONE_NORMAL. The difference is > > + that most pages in ZONE_MOVABLE are movable. That means that while virtual > > + addresses of these pages do not change, their content may move between > > + different physical pages. ZONE_MOVABLE is only enabled when one of > > + `kernelcore`, `movablecore` and `movable_node` parameters is present in the > > + kernel command line. See :ref:`Page migration ` for > > + additional details. > > + > > +`ZONE_DEVICE` > > + represents memory residing on devices such as PMEM and GPU. It has different > > + characteristics than RAM zone types and it exists to provide :ref:`struct > > + page ` and memory map services for device driver identified physical > > + address ranges. ZONE_DEVICE is enabled with configuration option > > + ``CONFIG_ZONE_DEVICE``. > > I think bullet lists should do the job better, since the zone names are > connected directly to their representations: Agree. > > +For example, with 32-bit kernel on an x86 UMA machine with 2 Gbytes of RAM the > > +entire memory will be on node 0 and there will be three zones: ZONE_DMA, > > +ZONE_NORMAL and ZONE_HIGHMEM:: > > + > > + 0 2G > > + +-------------------------------------------------------------+ > > + | node 0 | > > + +-------------------------------------------------------------+ > > + > > + 0 16M 896M 2G > > + +----------+-----------------------+--------------------------+ > > + | ZONE_DMA | ZONE_NORMAL | ZONE_HIGHMEM | > > + +----------+-----------------------+--------------------------+ > > + > > + > > +With a kernel built with ZONE_DMA disabled and ZONE_DMA32 enabled and booted > > +with `movablecore=80%` parameter on an arm64 machine with 16 Gbytes of RAM > > +equally split between two nodes, there will be ZONE_DMA32, ZONE_NORMAL and > > +ZONE_MOVABLE on node 0, and ZONE_NORMAL and ZONE_MOVABLE on node 1:: > > + > > + > > + 1G 9G 17G > > + +--------------------------------+ +--------------------------+ > > + | node 0 | | node 1 | > > + +--------------------------------+ +--------------------------+ > > + > > + 1G 4G 4200M 9G 9320M 17G > > + +---------+----------+-----------+ +------------+-------------+ > > + | DMA32 | NORMAL | MOVABLE | | NORMAL | MOVABLE | > > + +---------+----------+-----------+ +------------+-------------+ > > I see inconsistency of formatting keywords: some are in inline code and some > are not. I'm leaning towards inlining them all: Sure, thanks for the patch :) > > +For various operations possible with nodemasks please refer to > > +`include/linux/nodemask.h > > +`_. > > Instead of linking to Linus's tree, just inline the source path: Ok. > > +.. _zones: > > + > > +Zones > > +===== > > + > > +.. _pages: > > + > > +Pages > > +===== > > + > > +.. _folios: > > + > > +Folios > > +====== > > + > > +.. _initialization: > > + > > +Initialization > > +============== > > Are these sections stubs (no fields list for each types)? If so, add > admonitions to inform readers: Ok. -- Sincerely yours, Mike.