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 24B1BC67861 for ; Fri, 5 Apr 2024 16:49:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CE396B0088; Fri, 5 Apr 2024 12:49:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87EB36B0089; Fri, 5 Apr 2024 12:49:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7468D6B008C; Fri, 5 Apr 2024 12:49:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 51DE26B0088 for ; Fri, 5 Apr 2024 12:49:30 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BEC881411C5 for ; Fri, 5 Apr 2024 16:49:29 +0000 (UTC) X-FDA: 81976064058.21.1B17523 Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by imf22.hostedemail.com (Postfix) with ESMTP id 1CC45C0013 for ; Fri, 5 Apr 2024 16:49:27 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UfXTjZNg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of mcassell411@gmail.com designates 209.85.210.42 as permitted sender) smtp.mailfrom=mcassell411@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712335768; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=1Q301Hmu4jkyy54Tck51kniDcTmciVu05IC0+dyM5+M=; b=uzCMAy3JdkFV8Aq5ALJCRyYiNtvFCKuBoB+dMZfJ0CrlYHDQlV7utn4cHm3pAylISVloJD asFmas2C7K+H2TG39GIfJYX2k+KUcUEAiiOVtwRDQZ71LNUx/zc3mivFAoFqn9SsclAxLY /woRgi+lvCvYSTftge21cGDPMK+rfE0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UfXTjZNg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of mcassell411@gmail.com designates 209.85.210.42 as permitted sender) smtp.mailfrom=mcassell411@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712335768; a=rsa-sha256; cv=none; b=eVL9CgLGTvQj9xjPgC31Qp3HC67dFDcKrdouayv+1Al+wdKG7pHw/O1qFeIF415JweclZ1 u2FzKvOnVjVVjg6cAnUKgbtCAxWoyv54CamAxGofxo2+u1+H9Ylaje4wTdNMr2QqbClQk1 9LIkU4DyeX3P2bH6zFBGduvivHr0pBU= Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-6e125818649so789917a34.1 for ; Fri, 05 Apr 2024 09:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712335765; x=1712940565; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=1Q301Hmu4jkyy54Tck51kniDcTmciVu05IC0+dyM5+M=; b=UfXTjZNgBKEcViNxdxYAsFb8lwxMXXE5r2cWckaazDUR8r0Ce+E8vgSqLMWNhbKPJA sQGRBBa9sUj3MGUkYpYqjUOYxB/XtnHnjNbZL/igGuQTP+hC+D9PbK21sf3eKslGDqdP djwb8LjMy/FvfQ94+SjLpwHXtJlnWP7ZwUQUa6vJqDxqeHWu+30zNFkb7nXg4cg4yBpV lYLvPn26osrNcHXGaTL1Zn7RdrpfSbNexHlnbBKSCTl1WLB6P59hiOK+IXF+kYf9EbKB s5oaVga8QyibjxZ1j087tXxZ3ME1WIf3QJpM/pf0JPg0YVME9O1LQnItM8rzOd6yBXmv q9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712335765; x=1712940565; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1Q301Hmu4jkyy54Tck51kniDcTmciVu05IC0+dyM5+M=; b=aNVPwYclCYj7zZtzoysVVFBJLsYMNAF6NxA7BZqOXL0XAk917yQVCRtL8oByfWx43n bdU78+cMjw6v0lC7VQHqu5bAi80Jl5NGy5qjg2s9AS+Q9KAOl+zKh2tgiPlZflBzCLGK NDmFhnVwXkQVZOX1ZsmM/p7em91j90HAKZEtgKyf4AN/8oaaEYOfCA4StWzGP5sFWSQI fTfGGc8Qx8ukAPompnQglmW/+JnuiuZwZBQMnsPOs6PmpQC/WvpxRoX22cYz/zJ6x7kK iHHQlqHdKs6hekOu+jueP7zhlSnVd7PZSyJ+JN69G0othgXOGeEn37aE0kde+zCaCgWx BGmg== X-Gm-Message-State: AOJu0Ywy30K+lJkmyQ7C/oWn0jFY9stLUzGgxpKnaVHW1xwMYAQMm/NE vWIfTdsQGo50CDUApe4XOOHIkSbHN8gKTb6je6NWj4+XTX54DPa5 X-Google-Smtp-Source: AGHT+IEzk99QfVxQGmX333/pp4ac+5cgTfZoHLprBPeFsWR06+FIxuNZhd/TPqokoDumENH73G4qLg== X-Received: by 2002:a05:6830:1043:b0:6e9:e688:23eb with SMTP id b3-20020a056830104300b006e9e68823ebmr2026680otp.35.1712335765094; Fri, 05 Apr 2024 09:49:25 -0700 (PDT) Received: from localhost.localdomain (024-171-058-032.res.spectrum.com. [24.171.58.32]) by smtp.gmail.com with ESMTPSA id d25-20020a05683018f900b006e8aeb6706bsm340376otf.6.2024.04.05.09.49.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Apr 2024 09:49:24 -0700 (PDT) From: Matthew Cassell To: corbet@lwn.net, akpm@linux-foundation.org, vbendel@redhat.com, rppt@kernel.org Cc: linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, mcassell411@gmail.com Subject: [PATCH] Documentation/admin-guide/sysctl/vm.rst adding the importance of NUMA-node count to documentation Date: Fri, 5 Apr 2024 16:49:20 +0000 Message-Id: <20240405164920.2844-1-mcassell411@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: qfp9re1pjdiccfmiyeaj1btupcw8jg48 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1CC45C0013 X-HE-Tag: 1712335767-452715 X-HE-Meta: U2FsdGVkX18D9WQUuLLyrvTnorNMe+fzehyU5n2+IfM4cDTTCPQLbN6r7/p5XeUTm/LFauuRyi4K4/VGyb3b13M9bopUd7atvLz58uhbo+otJ0X+m8bFnvtHKaK0d9QUQvFmw9WtMmmoq3LKgbi3Hqli2+y7PYNb01plxCEViGVwgOZHq6MnzufV+JlAOpPIaoW84QsS4UFOdeH1saK4j++ewZBmSH9CAdeIRjh0MlqzCwOtnTxnvc69d8P2FUmcRiVVjWsNySVqHkR6SLgpGFj1j1fhTNhCvjCLhk8X2UGiecmAmzMlPFU/CRQTPKCmlHfdwsWMTUd6NjsnYvWraYRc2jmLczpWCiZ4vAcuiZ/1Sg6p2W4sCKRqRyRqowNT9suz8UeQeRDiPRzu8Aq4DPY6ykcWFfGDb9lRfZLwME0B4rvI1STs0UQ+iMai0ZhefrpdUSzbTyuIB4y2Iu5ubg84Uha+rTaT9iVJj/ADWRKD+Cuewnr6NdCJqISdMf9dH0wh434XzdvhoNtgAoe/ivnxrz5Va92UZB1a69y2CZX4q6MC2Twt/sWbgYDdidKkK+pKAcv5BYgfW19lULHvR7Uw8R8FvLKmNGE5+dddkNPAkPbYeTeT9Wf+FzhlN8sG66fHBPrE+QV9pe6xmns+ZrC5Hn1/KomsJ79MNmrDoMaqnKJpJ4fhv0AvHlnE5KuHUqidMM7S/sbcegRNZT8d8Z3C71hZvV3OBRBHUXzGBkuMmVbinjV3ZJAqEcXVZ3U+qHlWZLG+u/53DFmPyyU6EDa1XVtGXcQmkgbGOYcsuOZ52HUsQ7lCjKLjWAkHCKhd4rle0hXjUhDRUTVb+k/mmtcAlIZUVDs7t+VMvyXYKPRVNq184nZYIKdGVrjQZ1gnAYc9tP3bjRQ78rQE2mHM6buXu7UiUxnuCvj5DsrsNeFdTVXZcHtc+PiJqe0408A7TqYC7iG2PPJO6ac+ib5 VJGMKi9+ 6b5qk0E3ErUJ1EkQktAkQ5RDrlYCEXTZNT+QQJlZ+S4L/+O53I62mQGTPv+AJ7lagte+u2JLxgQP1UIlWIRVFNuKlc0nuU2Pa4fT8QH584WbrCltSXrB0uAvBV3HzSidx12/geqGMGp2hjqzTWovtRgzuZ+Q4lyMwcGKIW6gU9JddToX/5t+YjDuDPwQn/KwjzLlyGKP89aBURHW+GBFeSvD7ms/FWh9c54hEmjNaZkSiBBRqizA2d/PswdJIHg0c0cWzqzI3ht+SWi+IPIEhUUR3/XZkBaKBzkN5n5Hlw0oB8ub6vgX5yU5xL3j5Kn8kxX9pAW4qN0Zw8MkhhYdtChSNv5eZA3AY5EuTDj+Exv3mD/VP1lTJp7l9LJqQxlDmZa3hM0q+b5z7Ar+BjmdsCzGsw4qnZWWG/pyy/TQ3LIV6cw5nj/rRq/ETkZ7BkOnyKiov 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: List-Subscribe: List-Unsubscribe: If any bits are set in node_reclaim_mode (tunable via /proc/sys/vm/zone_reclaim_mode) within get_pages_from_freelist(), then page allocations start getting early access to reclaim via the node_reclaim() code path when memory pressure increases. This behavior provides the most optimization for multiple NUMA node machines. The above is mentioned in: Commit 9eeff2395e3cfd05c9b2e6 ("[PATCH] Zone reclaim: Reclaim logic") states "Zone reclaim is of particular importance for NUMA machines. It can be more beneficial to reclaim a page than taking the performance penalties that come with allocating a page on a REMOTE zone." While the pros/cons of staying on node versus allocating remotely are mentioned in commit histories and mailing lists. It isn't specifically mentioned in Documentation/ and isn't possible with a lone node. Imagine a situation where CONFIG_NUMA=y (the default on most major distributions) and only a single NUMA node exists. The latter is an oxymoron (single-node == uniform memory access). Informing the user via vm.rst that the most bang for their buck is when multiple nodes exist seems helpful. Signed-off-by: Matthew Cassell --- Documentation/admin-guide/sysctl/vm.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index c59889de122b..10270548af2a 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -1031,7 +1031,8 @@ Consider enabling one or more zone_reclaim mode bits if it's known that the workload is partitioned such that each partition fits within a NUMA node and that accessing remote memory would cause a measurable performance reduction. The page allocator will take additional actions before -allocating off node pages. +allocating off node pages. Keep in mind enabling bits in zone_reclaim_mode +makes the most sense for topologies consisting of multiple NUMA nodes. Allowing zone reclaim to write out pages stops processes that are writing large amounts of data from dirtying pages on other nodes. Zone -- 2.34.1