Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2616892iog; Sun, 26 Jun 2022 22:05:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vs0V3J0qCQ0C8uBmNelBdfuWXZR6Q/e4dsxdgCE0oITdL2buiXn3bf3ruwcpSDHsyaGOZq X-Received: by 2002:a05:6a00:b8b:b0:51b:eefc:7fd2 with SMTP id g11-20020a056a000b8b00b0051beefc7fd2mr12493104pfj.74.1656306317625; Sun, 26 Jun 2022 22:05:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656306317; cv=none; d=google.com; s=arc-20160816; b=gOce6AGJpMz1kNLn6SJ0abZKWr+9ZNzfluUSJmRjHnrqsjIErLeV5vAWwSO5Dikhu0 g7Q2A55aVJhR1bWwLYCh+Tn8VnTL6U9Ke/nKUzuwOrgmkWFNfd5mKfAlFJmX187KQ7jt PSkeph9nL4OtBsrkSL0NBvyQoEBtz8j3/nuZN7+uv1OjrzX4DIcFV+GV9RwG6xcmPE2t ezEut6vBgPQ7KuEAig4ZGfTkmr8dg2biSLNeVWiViiwDJzOLJMageJ3fOppbRsz1XGST W67gD7hiGXPcT444xQY9AEZmTveszAlBYUo2CnR2eY6g+QxzvV/aFyDCNA6XBwTIPp/I YqEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=X5IXJsh+NQ8VHaFe6RBYacgzLr/AWbAQyLQdscvjKIk=; b=DCwCLnCMs94dNXSqnRAkSJsqDOBWPLlyde0FFa6CNGrpxyA0G/36fY3d5bDNjgKjzb 10dKVvzE9cteFPL0iAkULi4zlHKM6hHH9mV2k4/DJlOQlduWbYMza5/bOVY9dCXve59g kLhgf0LJXiGP4FlavjrbR72uNhVnmzTp333vaRcQKJ14kV6y+3X1og1NMmojrTsKozbD k3IM17S09TLwKtRWpTjj3ORBAssZmFLyzM5NZZZqJl/cGUlrUEMw/ZB7XH2CTr8Wp/ld bUg0sDwoWWjIms7Rb2apnRvqD1ex4lSonGDqkw/3L7/2o/4GKZcUaDlraBUyh2WFsGPq hkDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=kVEkHcrF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a8-20020a655c88000000b00403f98eb964si12311433pgt.202.2022.06.26.22.05.03; Sun, 26 Jun 2022 22:05:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=kVEkHcrF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231577AbiF0Elh (ORCPT + 99 others); Mon, 27 Jun 2022 00:41:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229519AbiF0Elg (ORCPT ); Mon, 27 Jun 2022 00:41:36 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E15BB138; Sun, 26 Jun 2022 21:41:34 -0700 (PDT) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25R3LsI5001481; Mon, 27 Jun 2022 04:41:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : content-type : mime-version; s=pp1; bh=X5IXJsh+NQ8VHaFe6RBYacgzLr/AWbAQyLQdscvjKIk=; b=kVEkHcrFo0wfjaKkOJ/w9vIVbjJXy2P6DIGX1UoO1HHB4IMw8Vf9R9n20tLkvG8OBWOj yHeLvHK/99WnDKP74cSyx5gcEXWVChYjzugQML+dfHW9mXbk/DMwBL0zCIcED4uk+MJm hLFVvAdJIjbL0nQpPz7qF0MOEB9p1Qc1BbaXdILAgQFjMcHIKFvM21nDQjsJQxpgixNI 9CJ+7gT4jO7bfr2I1CVLeowxp3NHBWRfucvzCG/YDF0XRJDs3PntMTLcODpSHAnjxHKI uYKCNrHBnJFAVsKRVozgyLyfz96JdF690jZPcqs2z/356/GOtcqxY6+kIE9UvErE9bMN ow== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3gy4k31bk2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jun 2022 04:41:08 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 25R4aJSx012951; Mon, 27 Jun 2022 04:41:08 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3gy4k31bjh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jun 2022 04:41:08 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 25R4atDu012295; Mon, 27 Jun 2022 04:41:07 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma01dal.us.ibm.com with ESMTP id 3gwt09415r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jun 2022 04:41:06 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 25R4f5iZ15729366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Jun 2022 04:41:06 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CFD88C605F; Mon, 27 Jun 2022 04:41:05 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 76B2BC6055; Mon, 27 Jun 2022 04:40:59 +0000 (GMT) Received: from skywalker.linux.ibm.com (unknown [9.43.47.235]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 27 Jun 2022 04:40:59 +0000 (GMT) X-Mailer: emacs 29.0.50 (via feedmail 11-beta-1 I) From: "Aneesh Kumar K.V" To: Bagas Sanjaya Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Wei Xu , Huang Ying , Yang Shi , Davidlohr Bueso , Tim C Chen , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Jagdish Gediya , linux-doc@vger.kernel.org Subject: Re: [PATCH v7 11/12] mm/demotion: Add documentation for memory tiering In-Reply-To: References: <20220622082513.467538-1-aneesh.kumar@linux.ibm.com> <20220622082513.467538-12-aneesh.kumar@linux.ibm.com> Date: Mon, 27 Jun 2022 10:10:56 +0530 Message-ID: <87a69yzpk7.fsf@linux.ibm.com> Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: WkxdDUgPCgiW6TnpzOOKDuL4bxD3FWI2 X-Proofpoint-ORIG-GUID: wN5EjCrF8A3Ayf2J_qHyGotWpPDuWb3O X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-06-27_02,2022-06-24_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 suspectscore=0 mlxlogscore=999 adultscore=0 spamscore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206270020 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bagas Sanjaya writes: > On Wed, Jun 22, 2022 at 01:55:12PM +0530, Aneesh Kumar K.V wrote: >> From: Jagdish Gediya >> > > Hi Aneesh and Jagdish, > > The documentation can be improved, see below. > >> All N_MEMORY nodes are divided into 3 memoty tiers with tier ID value >> MEMORY_TIER_HBM_GPU, MEMORY_TIER_DRAM and MEMORY_TIER_PMEM. By default, >> all nodes are assigned to default memory tier. >> >> Demotion path for all N_MEMORY nodes is prepared based on the tier ID value >> of memory tiers. >> >> This patch adds documention for memory tiering introduction, its sysfs >> interfaces and how demotion is performed based on memory tiers. >> > > I think the patch message should just be: > "Add documentation for memory tiering. It also covers its sysfs > interfaces and how demotion is performed based on memory tiers." > >> +=========== >> +Memory tiers >> +============ >> + >> +This document describes explicit memory tiering support along with >> +demotion based on memory tiers. >> + > > This causes htmldocs error, for which I have applied the fixup at [1]. > >> +Memory nodes are divided into 3 types of memory tiers with tier ID >> +value as shown based on their hardware characteristics. >> + >> + >> +MEMORY_TIER_HBM_GPU >> +MEMORY_TIER_DRAM >> +MEMORY_TIER_PMEM >> + > > Use bullet list. > >> +Sysfs interfaces >> +================ >> + >> +Nodes belonging to specific tier can be read from, >> +/sys/devices/system/memtier/memtierN/nodelist (Read-Only) >> + >> +Where N is 0 - 2. > > The "where" sentence can be compounded into the previous sentence above. > >> + >> +Example 1: >> +For a system where Node 0 is CPU + DRAM nodes, Node 1 is HBM node, >> +node 2 is a PMEM node an ideal tier layout will be >> + >> +$ cat /sys/devices/system/memtier/memtier0/nodelist >> +1 >> +$ cat /sys/devices/system/memtier/memtier1/nodelist >> +0 >> +$ cat /sys/devices/system/memtier/memtier2/nodelist >> +2 >> + > > The code snippets should have been inside literal code blocks. > >> +Example 2: >> +For a system where Node 0 & 1 are CPU + DRAM nodes, node 2 & 3 are PMEM >> +nodes. >> + >> +$ cat /sys/devices/system/memtier/memtier0/nodelist >> +cat: /sys/devices/system/memtier/memtier0/nodelist: No such file or >> +directory >> +$ cat /sys/devices/system/memtier/memtier1/nodelist >> +0-1 >> +$ cat /sys/devices/system/memtier/memtier2/nodelist >> +2-3 >> + > > Use literal code block. > >> +Default memory tier can be read from, >> +/sys/devices/system/memtier/default_tier (Read-Only) >> + >> +e.g. >> +$ cat /sys/devices/system/memtier/default_tier >> +memtier200 >> + >> +Max memory tier ID supported can be read from, >> +/sys/devices/system/memtier/max_tier (Read-Only) >> + >> +e.g. >> +$ cat /sys/devices/system/memtier/max_tier >> +400 >> + >> +Individual node's memory tier can be read of set using, >> +/sys/devices/system/node/nodeN/memtier (Read-Write) >> + >> +where N = node id >> + >> +When this interface is written, Node is moved from the old memory tier >> +to new memory tier and demotion targets for all N_MEMORY nodes are >> +built again. >> + >> +For example 1 mentioned above, >> +$ cat /sys/devices/system/node/node0/memtier >> +1 >> +$ cat /sys/devices/system/node/node1/memtier >> +0 >> +$ cat /sys/devices/system/node/node2/memtier >> +2 >> + > > The same suggestions above apply here, too. > >> +Enable/Disable demotion >> +----------------------- >> + >> +By default demotion is disabled, it can be enabled/disabled using >> +below sysfs interface, >> + >> +$ echo 0/1 or false/true > /sys/kernel/mm/numa/demotion_enabled >> + > > Use literal code block. > >> +preferred and allowed demotion nodes >> +------------------------------------ >> + >> +Preferred nodes for a specific N_MEMORY node are the best nodes >> +from the next possible lower memory tier. Allowed nodes for any >> +node are all the nodes available in all possible lower memory >> +tiers. >> + >> +Example: >> + >> +For a system where Node 0 & 1 are CPU + DRAM nodes, node 2 & 3 are PMEM >> +nodes, >> + >> +node distances: >> +node 0 1 2 3 >> + 0 10 20 30 40 >> + 1 20 10 40 30 >> + 2 30 40 10 40 >> + 3 40 30 40 10 >> + > > Use reST table. > >> +memory_tiers[0] = >> +memory_tiers[1] = 0-1 >> +memory_tiers[2] = 2-3 >> + >> +node_demotion[0].preferred = 2 >> +node_demotion[0].allowed = 2, 3 >> +node_demotion[1].preferred = 3 >> +node_demotion[1].allowed = 3, 2 >> +node_demotion[2].preferred = >> +node_demotion[2].allowed = >> +node_demotion[3].preferred = >> +node_demotion[3].allowed = >> + > > What are these above? Node properties? BTW, use literal code block. > > If you don't understand these suggestions above, here is the diff: I got with the below diff. patch: **** malformed patch at line 180: @@ -148,35 +153,40 @@ from the next possible lower memory tier. Allowed nodes for any But I did modify the documentation based on your feedback and it is much better than what I had. Thanks for the review. I will send v8 with the changes folded. I did add the below to commit message. Hope that is ok. [update doc format by Bagas Sanjaya ] > > ---- >8 ---- > > diff --git a/Documentation/admin-guide/mm/memory-tiering.rst b/Documentation/admin-guide/mm/memory-tiering.rst > index 0a75e0dab1fd8e..10ec5aab6ddd53 100644 > --- a/Documentation/admin-guide/mm/memory-tiering.rst > +++ b/Documentation/admin-guide/mm/memory-tiering.rst > @@ -14,13 +14,13 @@ Introduction > > Many systems have multiple types of memory devices e.g. GPU, DRAM and > PMEM. The memory subsystem of these systems can be called a memory > -tiering system because the performance of the different types of > +tiering system because the performance of each type of > memory is different. Memory tiers are defined based on the hardware > capabilities of memory nodes. Each memory tier is assigned a tier ID > value that determines the memory tier position in demotion order. > > The memory tier assignment of each node is independent of each > -other. Moving a node from one tier to another tier doesn't affect > +other. Moving a node from one tier to another doesn't affect > the tier assignment of any other node. > > Memory tiers are used to build the demotion targets for nodes. A node > @@ -32,10 +32,9 @@ Memory tier rank > Memory nodes are divided into 3 types of memory tiers with tier ID > value as shown based on their hardware characteristics. > > - > -MEMORY_TIER_HBM_GPU > -MEMORY_TIER_DRAM > -MEMORY_TIER_PMEM > + * MEMORY_TIER_HBM_GPU > + * MEMORY_TIER_DRAM > + * MEMORY_TIER_PMEM > > Memory tiers initialization and (re)assignments > =============================================== > @@ -49,68 +48,73 @@ hotplug, the memory tier with default tier ID is assigned to the memory node. > Sysfs interfaces > ================ > > -Nodes belonging to specific tier can be read from, > -/sys/devices/system/memtier/memtierN/nodelist (Read-Only) > +Nodes belonging to specific tier can be read from > +/sys/devices/system/memtier/memtierN/nodelist, where N is 0 - 2 (read-only) > > -Where N is 0 - 2. > +Examples: > > -Example 1: > -For a system where Node 0 is CPU + DRAM nodes, Node 1 is HBM node, > -node 2 is a PMEM node an ideal tier layout will be > +1. On a system where Node 0 is CPU + DRAM nodes, Node 1 is HBM node, > + node 2 is a PMEM node an ideal tier layout will be: > > -$ cat /sys/devices/system/memtier/memtier0/nodelist > -1 > -$ cat /sys/devices/system/memtier/memtier1/nodelist > -0 > -$ cat /sys/devices/system/memtier/memtier2/nodelist > -2 > + .. code-block:: > > -Example 2: > -For a system where Node 0 & 1 are CPU + DRAM nodes, node 2 & 3 are PMEM > -nodes. > + $ cat /sys/devices/system/memtier/memtier0/nodelist > + 1 > + $ cat /sys/devices/system/memtier/memtier1/nodelist > + 0 > + $ cat /sys/devices/system/memtier/memtier2/nodelist > + 2 > > -$ cat /sys/devices/system/memtier/memtier0/nodelist > -cat: /sys/devices/system/memtier/memtier0/nodelist: No such file or > -directory > -$ cat /sys/devices/system/memtier/memtier1/nodelist > -0-1 > -$ cat /sys/devices/system/memtier/memtier2/nodelist > -2-3 > +2. On a system where Node 0 & 1 are CPU + DRAM nodes, node 2 & 3 are PMEM > + nodes: > > -Default memory tier can be read from, > -/sys/devices/system/memtier/default_tier (Read-Only) > + .. code-block:: > > -e.g. > -$ cat /sys/devices/system/memtier/default_tier > -memtier200 > + $ cat /sys/devices/system/memtier/memtier0/nodelist > + cat: /sys/devices/system/memtier/memtier0/nodelist: No such file or > + directory > + $ cat /sys/devices/system/memtier/memtier1/nodelist > + 0-1 > + $ cat /sys/devices/system/memtier/memtier2/nodelist > + 2-3 > > -Max memory tier ID supported can be read from, > -/sys/devices/system/memtier/max_tier (Read-Only) > +Default memory tier can be read from > +/sys/devices/system/memtier/default_tier (read-only), e.g.: > > -e.g. > -$ cat /sys/devices/system/memtier/max_tier > -400 > +.. code-block:: > > -Individual node's memory tier can be read of set using, > -/sys/devices/system/node/nodeN/memtier (Read-Write) > + $ cat /sys/devices/system/memtier/default_tier > + memtier200 > > -where N = node id > +Max memory tier ID supported can be read from > +/sys/devices/system/memtier/max_tier (read-only), e.g.: > > -When this interface is written, Node is moved from the old memory tier > +.. code-block:: > + > + $ cat /sys/devices/system/memtier/max_tier > + 400 > + > +Individual node's memory tier can be read or set using > +/sys/devices/system/node/nodeN/memtier (read-write), where N = node id. > + > +When this interface is written, node is moved from the old memory tier > to new memory tier and demotion targets for all N_MEMORY nodes are > built again. > > -For example 1 mentioned above, > -$ cat /sys/devices/system/node/node0/memtier > -1 > -$ cat /sys/devices/system/node/node1/memtier > -0 > -$ cat /sys/devices/system/node/node2/memtier > -2 > +For example 1 mentioned above: > + > +.. code-block:: > + > + $ cat /sys/devices/system/node/node0/memtier > + 1 > + $ cat /sys/devices/system/node/node1/memtier > + 0 > + $ cat /sys/devices/system/node/node2/memtier > + 2 > > Additional memory tiers can be created by writing a tier ID value to this file. > -This results in a new memory tier creation and moving the specific NUMA node to > -that memory tier. > +This results into creating a new tier and moving the specific NUMA node to > +that tier. > > Demotion > ======== > @@ -128,19 +132,20 @@ be used. > > Instead of a page being discarded during reclaim, it can be moved to > persistent memory. Allowing page migration during reclaim enables > -these systems to migrate pages from fast(higher) tiers to slow(lower) > -tiers when the fast(higher) tier is under pressure. > +these systems to migrate pages from fast (higher) tiers to slow (lower) > +tiers when the fast (higher) tier is under pressure. > > > Enable/Disable demotion > ----------------------- > > -By default demotion is disabled, it can be enabled/disabled using > -below sysfs interface, > +By default demotion is disabled. It can be toggled by: > > -$ echo 0/1 or false/true > /sys/kernel/mm/numa/demotion_enabled > +.. code-block:: > > -preferred and allowed demotion nodes > + $ echo 0/1 or false/true > /sys/kernel/mm/numa/demotion_enabled > + > +Preferred and allowed demotion nodes > ------------------------------------ > > Preferred nodes for a specific N_MEMORY node are the best nodes > @@ -148,35 +153,40 @@ from the next possible lower memory tier. Allowed nodes for any > node are all the nodes available in all possible lower memory > tiers. > > -Example: > +For example, on a system where Node 0 & 1 are CPU + DRAM nodes, > +node 2 & 3 are PMEM nodes: > > -For a system where Node 0 & 1 are CPU + DRAM nodes, node 2 & 3 are PMEM > -nodes, > + * node distances > > -node distances: > -node 0 1 2 3 > - 0 10 20 30 40 > - 1 20 10 40 30 > - 2 30 40 10 40 > - 3 40 30 40 10 > + ==== == == == == > + node 0 1 2 3 > + ==== == == == == > + 0 10 20 30 40 > + 1 20 10 40 30 > + 2 30 40 10 40 > + 3 40 30 40 10 > + ==== == == == == > > -memory_tiers[0] = > -memory_tiers[1] = 0-1 > -memory_tiers[2] = 2-3 > + * node properties > > -node_demotion[0].preferred = 2 > -node_demotion[0].allowed = 2, 3 > -node_demotion[1].preferred = 3 > -node_demotion[1].allowed = 3, 2 > -node_demotion[2].preferred = > -node_demotion[2].allowed = > -node_demotion[3].preferred = > -node_demotion[3].allowed = > + .. code-block:: > + > + memory_tiers[0] = > + memory_tiers[1] = 0-1 > + memory_tiers[2] = 2-3 > + > + node_demotion[0].preferred = 2 > + node_demotion[0].allowed = 2, 3 > + node_demotion[1].preferred = 3 > + node_demotion[1].allowed = 3, 2 > + node_demotion[2].preferred = > + node_demotion[2].allowed = > + node_demotion[3].preferred = > + node_demotion[3].allowed = > > Memory allocation for demotion > ------------------------------ > > -If a page needs to be demoted from any node, the kernel 1st tries > -to allocate a new page from the node's preferred node and fallbacks to > -node's allowed targets in allocation fallback order. > - > +If a page needs to be demoted from any node, the kernel first tries > +to allocate a new page from the node's preferred target node and fallbacks > +to node's allowed targets in allocation fallback order. > > > Thanks. > > [1]: https://lore.kernel.org/linux-doc/YrZ5cTFOSuWxlF2t@debian.me/ > > -- > An old man doll... just what I always wanted! - Clara