From patchwork Thu Jan 12 09:16:14 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 13097695 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 7E218C54EBC for ; Thu, 12 Jan 2023 09:16:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F02D78E0003; Thu, 12 Jan 2023 04:16:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB2A28E0001; Thu, 12 Jan 2023 04:16:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7B488E0003; Thu, 12 Jan 2023 04:16:37 -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 C950E8E0001 for ; Thu, 12 Jan 2023 04:16:37 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 85937120C2D for ; Thu, 12 Jan 2023 09:16:37 +0000 (UTC) X-FDA: 80345591634.26.E0551A4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id D1B9AA0017 for ; Thu, 12 Jan 2023 09:16:35 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NzaYABpJ; spf=pass (imf25.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673514995; 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:in-reply-to:references:references:dkim-signature; bh=RRQD42HKfR/LI9/uic1tlo6FDQUGDQlSUUKQEirwRuA=; b=hH+uUwLLA8u4TGnsGKtbwuA/E8d3BgLaoXtbiMInaNEfTukPlRJXbbOZKsbQzMIcuQrEOY sUyfN8A0pT0yObiGu9HPlLJNp0sPg7dlaPPG6t3YzboUMng3vjmCrCRXpS+6+Azwfh1KM7 gYac0SobS5uNa7Vmdki6STPqKIB/Iqw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NzaYABpJ; spf=pass (imf25.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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673514995; a=rsa-sha256; cv=none; b=OZ3eZ52kmYYpHktm7rxClDlBsFoz7HA3dkGC9cPbLFf3EBS/XtrjkEndRqGzrWTuuDyTIf F9reSKHiOQ1XTuHc6feUvOBS4wGFc7qv9E2RGb965gL8kKmdvq2F7aTDV6Z2gw8bahNmr5 34gR80+MJ6lXL240X9/2GzErlV3z5ac= 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 DCDE661FB7; Thu, 12 Jan 2023 09:16:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A86C8C4339C; Thu, 12 Jan 2023 09:16:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673514994; bh=oFc0IwWVLtbYv7DCWrnjSwABzc8JM/Pqrho6QIR7/GE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NzaYABpJWpMrVaVC4V4egtA8Eao1yIBWkjD8/cDjJ9WvmGsBeB6KBii81hggxnijA wtbaGG9hdGNUvP8xZ++YifcLHbFS87I7vFyKsO6JYzuTzuDcAmEaNRAGvnhlKlTTza wNfzDwU7SAQ+Uf2H8HHY4JeOvEMcJbUeohmOr5Xyh3inEV8ZqFoL97lKswQm20sMdF /CoQpEYqwe8QMpkMnLvNHhJYwoAsWGom7oajM7Ma4lXjdoAuR0BoQZDugHMGrqBKdJ BeNljZyQjFASbCQ01AEQGp/l0FhTWKW9CjPcYcJpQ25p4W8R1fyTYYoA4peBQv/grx cLnezprw+hStw== From: Mike Rapoport To: Jonathan Corbet Cc: Andrew Morton , Bagas Sanjaya , David Hildenbrand , Johannes Weiner , Lorenzo Stoakes , "Matthew Wilcox (Oracle)" , Mel Gorman , Michal Hocko , Mike Rapoport , Vlastimil Babka , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 1/3] docs/core-api: DMA API: add page label to allow external references Date: Thu, 12 Jan 2023 11:16:14 +0200 Message-Id: <20230112091616.824565-2-rppt@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20230112091616.824565-1-rppt@kernel.org> References: <20230112091616.824565-1-rppt@kernel.org> MIME-Version: 1.0 X-Rspamd-Queue-Id: D1B9AA0017 X-Stat-Signature: 9qx6ok7p74ni7tz8umbn1rgpruxq5n8g X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1673514995-451565 X-HE-Meta: U2FsdGVkX19pPQ+74zGZSk6ofJH5P6zuDEeU4Hit2UYZuY9YwSGeTc2CMPSTw9/Z1CjZbEleCvIkbnvnc2VEKBu2r9p8bcX2vFXYzI/kjYHJfU2czAXtNvPVRo7QiW2YSgPN3B3xIKACkPVYutvaK+4ZwRYfRp6q67l0DHKTLtem4LOay2U18yCDL9cld4Ig2EzyR5sMBPD7sOEY50Tbm58uh6Tw2T1qwTGCv5Kkc3mPvnoM+TzLj4YzHXgXdFH46NCFx3H2eafKcUNkRVG0l0AnrBJ9L4LD6M5tfyQ/ndRd5mjILSlT6VmP+wJ9XqRNCWhTOBdX5cPek/cV24rb01GDyT+uYgBwflxL3phy3E94cU3BDLf1xb0SdEKF0Nz7+fuVRhw4ZMmop04wdqKxXfc7MLqJV1wiWtBPBNI6X6RVP+VDlXQ0CONoPQb4ymaJO0bf+C0GPoWjbpbHYfL8SplsDrYPc34ARsU3sn7fcU/OIKV322XniU3f7Ea4IfT7+LP8n8hfX2vj0nRBrPj1YyApKAprb/RwV8YYaNNs8TS0Urcy0bIRSdHxJxwOqLjHJlnuwgwAx+anaQqRI4vnjp+ZYeeyBZbdp9lATbR2qTmUqqLAh9Llho/BrZZYfSDruOM53FsF3QNK5RL81/XIHxncC17u1A9XDNRPclHUln9w6Q6NY+2pjXdLRbxlA0gHxazDKV3k786oNsENGolLwcpQRTuhJXzjm5A1tWhO3if7j9cOdZYfb/moqOhGyY2StLyFYs2FWHNy/84kpQc/apZNbITxt9+RTQUw24eWnV7TT9Mce8lccEBUgZ46Ymy8D3rhBWox1JjLENZ3juMxIcHfUkEvgeaj4WKkeuiBg98blFmmFK4ty9dB5eFJ2pnBy8jMmI5SLwB9SBMmM2xSyHuRJiYk0JeEMZDEdTQF3LD8q/4C82Fp50wu0AxXGzJNABB852zYP8ZfTcKHqpY AvCsMVHi sUQefeB18/uMqVfJ9wszEGgRIWKVCr+0cHNzLKEGURm2OxJLOkkHOXILroMNtVFog7N5Axt0ppSCn6b4= 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: From: "Mike Rapoport (IBM)" Signed-off-by: Mike Rapoport (IBM) --- Documentation/core-api/dma-api.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst index 829f20a193ca..c847a5b0a0d3 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -1,3 +1,5 @@ +.. _dma_api: + ============================================ Dynamic DMA mapping using the generic device ============================================ From patchwork Thu Jan 12 09:16:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 13097696 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 9036DC54EBC for ; Thu, 12 Jan 2023 09:16:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BDB48E0005; Thu, 12 Jan 2023 04:16:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 16D9D8E0001; Thu, 12 Jan 2023 04:16:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 034568E0005; Thu, 12 Jan 2023 04:16:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EAE418E0001 for ; Thu, 12 Jan 2023 04:16:41 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 83600140B9C for ; Thu, 12 Jan 2023 09:16:41 +0000 (UTC) X-FDA: 80345591802.22.F45EB4B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id EC03D40017 for ; Thu, 12 Jan 2023 09:16:39 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HyrCYlau; spf=pass (imf27.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673515000; 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:in-reply-to:references:references:dkim-signature; bh=GeMxW6/bo7t8CedbH0ljza4tMQodK6qFd732yujZOBQ=; b=oV0HqYnTkoO6Q4X91vFlwBiO6GORbAkRQBJhZHAdmmaOwcYyPpUtXbcBMGzyWKgyNzTcGP iKgqPN04eULjIfntnykarAdRCdOKEHk9SWb6I0J9q3Q1r+eRck98RJaffUEueezq0HVhNy KfjVhGE20Ebpsw7GHmXVvimH+BtbicY= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HyrCYlau; spf=pass (imf27.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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673515000; a=rsa-sha256; cv=none; b=fx1Pznq1Ryg8ziJLKKjN/XsH5iYjBWkfpvT5RNuhzRmuKpODZHOFBc61acIml3sPFIOCUL EXdIKv7ofAhOPDaLUsF8Bo6bdhjXloK559nWZzfXBRtU9fzIc6SqjQhXYDCtfkd5SSAarv vMpeLwjWqH+B2Zck6LMB8YX9Dq933Kw= 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 0C10B61FAF; Thu, 12 Jan 2023 09:16:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D334EC433D2; Thu, 12 Jan 2023 09:16:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673514998; bh=ZLGBlhqw5hH+SxGqvaz0vux+DdR7ulM6iEJUTeGEBI0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HyrCYlauX4PXXWG5WJaiDDyQ5apznezA6+yxRixMw+fXqLMA9iCiRDXMGTAO70fiA bz0Mg/CmqB+nGiH3/sPByRAk1piYnULBmzuDGgK1oFD44IJL/TjCwMr4VCBOo8j4CP UDT62N1CTljHSZgf8HbyBAjWE5JwhdziCHvDB8oxa8g9xuQkXvbSwuTLHfQfyvrHrs f3b3Rr7MKmE6O9KwPi9GE4xseySelMz+yRPsMpepqCiT5gG7S9cm7Y1TVV8KLV2Hbf BtmIJZ/lHJ30Lir8ygtARKpluG0sskKiXNHLpwFwqqOCKyTZpdeP7jfpj7TNGGGfAq 6qu3FoZFr5R0Q== From: Mike Rapoport To: Jonathan Corbet Cc: Andrew Morton , Bagas Sanjaya , David Hildenbrand , Johannes Weiner , Lorenzo Stoakes , "Matthew Wilcox (Oracle)" , Mel Gorman , Michal Hocko , Mike Rapoport , Vlastimil Babka , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 2/3] docs/mm: Page Reclaim: add page label to allow external references Date: Thu, 12 Jan 2023 11:16:15 +0200 Message-Id: <20230112091616.824565-3-rppt@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20230112091616.824565-1-rppt@kernel.org> References: <20230112091616.824565-1-rppt@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EC03D40017 X-Stat-Signature: fch73sd9gtr4beu4144zar33prszdmwy X-Rspam-User: X-HE-Tag: 1673514999-585349 X-HE-Meta: U2FsdGVkX18xSVx+8cYs+Xz69ayWAHNPi7pUdSysID0TLkJjQNEUpIr49xoCskHczE6y+lkaFfcFKknYIdVYUTjeCvd7o70FOnXiBk57WoAMzmQ5zcCggT1MTp1hs1tcgSFRGBLS67sxJIeEx8GtIreBQOD2F8ynOyKZ194WK2jUH95ksb6BMqdmTYaSUg0r7IgqmnPP6Hn42cFijWDwJTN+I9q0kUNrv+eYPrNOMmC+49q0ghXnNN/OWPhCE89ewB3plUCOBv2guHJgCK3Yqytsw61nMKolaENKNV91nVCML2wE1sjOw4KupEnJkuU7PvEVrM8pQWI+611BvLPY7uQWvvmoxNxOrW8doybCgT5Y7DurOkgyFGKlTR1yniJ5TTXwp1zE27A9v2OTkdX3bH0qU58ktCAzhi0p3ywQ8FEENgIinOWlkCHaxZPe49BHP2ZzOYxGSs95pvAeIYht2a5qcKBmiftkvXvKRyDY+Bkl/gSMfmh6R+jC1TixpuIbqyl3pECa4+9UgkWdCjZQ4h5wLZTIhPn6SzT5lYjoVreRaNhVOMnCZ0Z2enohhrRtcb3qyh2KrVmSNZhNtB00M7eesWwv0GG+nbJIN8Dcup6FvDmBiwJOQmV2zBfcVB49VVwIM8vkoYFsoBbbqHEkaYClOkCrvWFh5qXz7qigqLjUy2iwiCo1223xHleqan1gZaryKbhbbouqRL4zTTcKRlKDJhYOZ7Gl1p7W5Ko2ogLqoN8/Q68npGDtVUjlHyO5dmobthbbrOj6TqgAsA8RylgqLGZwL2GZs2YJWZVxEE2xxNg2kzOPv7h0aah4G/GXNERDuKw5RaDXc9RrjNCogigQ0EqKcaUZlzpUQEcxc14PKJm93WqGKePCnEqaRW/znWRvxV06weReBoLInhZF6NMwNlHT1gXLUSwOI1uC6OqrQ613EBQIW+A+mK8dhO1IpBeJV8qaamyZcyLMplL KeBZ1N/S 2sCHYCw/RP0uEKHaMW4SXNkp/7JZBS844Ul4M9y5xXSdxkuhczN0Zf0+duzGc0tQFQFGJn7iyrtUYUtQ= 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: From: "Mike Rapoport (IBM)" Signed-off-by: Mike Rapoport (IBM) --- Documentation/mm/page_reclaim.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/mm/page_reclaim.rst b/Documentation/mm/page_reclaim.rst index 50a30b7f8ac3..3fccde066436 100644 --- a/Documentation/mm/page_reclaim.rst +++ b/Documentation/mm/page_reclaim.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +.. _page_reclaim: + ============ Page Reclaim ============ From patchwork Thu Jan 12 09:16:16 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 13097697 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 C4FB3C54EBC for ; Thu, 12 Jan 2023 09:16:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 565EF8E0006; Thu, 12 Jan 2023 04:16:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 515DE8E0001; Thu, 12 Jan 2023 04:16:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B77D8E0006; Thu, 12 Jan 2023 04:16:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2BB888E0001 for ; Thu, 12 Jan 2023 04:16:46 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DCA5FC0B4A for ; Thu, 12 Jan 2023 09:16:45 +0000 (UTC) X-FDA: 80345591970.13.C9E4EF0 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 4692220008 for ; Thu, 12 Jan 2023 09:16:44 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZI9dMC0r; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673515004; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3136EQaSwgOG6m+e8K/1QlUUAirmOerzHA+OsnU2g9U=; b=nzPKeJ76IXr0g67Y04TPIr5hy8dNxqEJAMjeiipx8bRgze8lW6Sm1YSKTAj7TsMSbq6chv RLqfaXtGL0bon6OLVZQXoDkQnSqNBJ/Vy2thJ1pxpR34J6AthUCIqlepNUKQ4GVpmBC/QH JW7L7XFYPS2Unk0jt1lkMo84AwV+GRk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZI9dMC0r; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673515004; a=rsa-sha256; cv=none; b=RzKBGmKgqHoK/fhjQD/dy1yX4LNexLDVd7kxlkXJBULrAGSvGn972VS4RXicbT6tbGscw3 YjIYF5D8sPu3Af0YiPVEv4mKCFBpnO14xVm7E7VNRg4hfbXC2SK4JzVdjvktAgUAQn+D7n 6FH4e+Bxo+2NpI+aqAOiRirMEDqx7dw= 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 690F261F83; Thu, 12 Jan 2023 09:16:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 053C5C43392; Thu, 12 Jan 2023 09:16:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673515002; bh=V+iTp2fjkkAm20fEdfSyZmV2I2f5Y8HxNdX7L5VTNvQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZI9dMC0rgw/GgRcbACAXwtl3Jf2iDQCkbWWYlvIwSf1FaZ3eUKD0n8mZKcPI8e7Va g+bPzNGMTK0XW4EpxTVsVvdQMW7YwRg/H6RWRLxf74eCHONbk/3PV65vHxiZLBh8Ch KYa3GMhNMbAcMVFeaqssFqATUY5nLaRhDWHCUE9DItA49CJ6I4TyRJ2d76LNMsLjRw ry+lLgZd/JMLlE1+u4XLCv+4PEqriArogGZZ+uxIr+13QTEZ+/kKzbDPszF7KJUhuE a2Z7eITUq4j617BlfXdqh0pobT5n6wPUpzEt5+6DbonBpQUcP8vbs3nhWJj9PDB/6k dQki7bl+z1o0Q== From: Mike Rapoport To: Jonathan Corbet Cc: Andrew Morton , Bagas Sanjaya , David Hildenbrand , Johannes Weiner , Lorenzo Stoakes , "Matthew Wilcox (Oracle)" , Mel Gorman , Michal Hocko , Mike Rapoport , Vlastimil Babka , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 3/3] docs/mm: Physical Memory: add structure, introduction and nodes description Date: Thu, 12 Jan 2023 11:16:16 +0200 Message-Id: <20230112091616.824565-4-rppt@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20230112091616.824565-1-rppt@kernel.org> References: <20230112091616.824565-1-rppt@kernel.org> MIME-Version: 1.0 X-Rspamd-Queue-Id: 4692220008 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: mis596s8so5w5nj9zm4jazufecwbgji7 X-HE-Tag: 1673515004-155339 X-HE-Meta: U2FsdGVkX19gjbMQKneqlj0JU4BhQY8sGX5RqBdu4xFBnuiqQaf0Q+9x97+3EzclNPPPGrVIrpJVC11tI2SWkWtguHgHFblomKJ2Uf15uucoFpZz0d33POp9rvKsApIi7Bat8QDYXkDuV4rmJSbUPos9NKFpfjbixO59s2imAjBOVluLt7EHxBHgpDTgPMqueU5H7dEPDLZmtdO4VVa1yxRdGGRKsGGiOtQV+FJT6q6qKllfQkoH15u2Xp1geC4ifkXEYE/5LOLKiYGoZ8VJV+YcIcMrGr3yMEiDLwAi9NDMfeyhAIkGJbBgykFZw6Cb4ufH7F2MATkJrCxVc+come2I6AydCwvAe7ULafcCkMfSthXtuRl8pUlrmBj37bv2poMhX4ruFhqCLDMp1+gTzOrPyVsiliGPBC6h7xBeqKR4vviLnGrmu8ZY/63eTsplbCPxtWRLFyM1bm8BekGDsaKQS7j1n2EdJ46tHhmcorUqVY6dMTUJpTHgYPTqAFu4ZCki2+02zK+IVpvs+YECZx1EuFX3IgcbT0FowLu7Qf52uWkbcvgCKcpaPuwfNWVT5kMO/qTWRJEaKaGjqMaVuliJp+OsTPrnpEwBAdxznQORFzMXb9oXlSCQAefWW1GxJC++S+WIKv6O5z/ae+xXTeXrXTKFA65cwzLNpgTBvTlg25IgTI6P81vg1Oi4E+D9+ND475NabNu0rAHCTGXLU9dqlnUjuRd1Vlq7ru3OROuTKcN2ke5Llu4WQtUYtlXZvTRBEfcOZrHkJkhrb/saVx0oqOsW+S5Lp9LxR3dbv/IzANSR9Af1cZpJWOSZtxzGCZf6ff+zTPu9PjJm/ev3GtTOzSMa/7fESG/lGKs6QM2AuyRmXHlamQDZmHwd/MZ/G7XazPTT5ZTrDWbw++Btvb+S2SIqYUvwJYSBYwDT965c3pjpLmB7icQ1rk0PtpHZ5ooftFJQspke4XTQjZB 5HNXikn/ s/2PGN4ttAWcaBU0M4fHd6L5wM3YuAf9Z0OOy 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: From: "Mike Rapoport (IBM)" Add structure, introduction and Nodes section to Physical Memory chapter. Signed-off-by: Mike Rapoport (IBM) Reviewed-by: Bagas Sanjaya Acked-by: Michal Hocko Reviewed-by: Lorenzo Stoakes --- Documentation/mm/physical_memory.rst | 346 +++++++++++++++++++++++++++ 1 file changed, 346 insertions(+) diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst index 2ab7b8c1c863..eed583af6985 100644 --- a/Documentation/mm/physical_memory.rst +++ b/Documentation/mm/physical_memory.rst @@ -3,3 +3,349 @@ =============== Physical Memory =============== + +Linux is available for a wide range of architectures so there is a need for an +architecture-independent abstraction to represent the physical memory. This +chapter describes the structures used to manage physical memory in a running +system. + +The first principal concept prevalent in the memory management is +`Non-Uniform Memory Access (NUMA) +`_. +With multi-core and multi-socket machines, memory may be arranged into banks +that incur a different cost to access depending on the “distance” from the +processor. For example, there might be a bank of memory assigned to each CPU or +a bank of memory very suitable for DMA near peripheral devices. + +Each bank is called a node and the concept is represented under Linux by a +``struct pglist_data`` even if the architecture is UMA. This structure is +always referenced to by it's typedef ``pg_data_t``. ``A pg_data_t`` structure +for a particular node can be referenced by ``NODE_DATA(nid)`` macro where +``nid`` is the ID of that node. + +For NUMA architectures, the node structures are allocated by the architecture +specific code early during boot. Usually, these structures are allocated +locally on the memory bank they represent. For UMA architectures, only one +static ``pg_data_t`` structure called ``contig_page_data`` is used. Nodes will +be discussed further in Section :ref:`Nodes ` + +The entire physical address space is partitioned into one or more blocks +called zones which represent ranges within memory. These ranges are usually +determined by architectural constraints for accessing the physical memory. +The memory range within a node that corresponds to a particular zone is +described by a ``struct zone``, typedeffed to ``zone_t``. Each zone has +one of the types described below. + +* ``ZONE_DMA`` and ``ZONE_DMA32`` historically represented memory suitable for + DMA by peripheral devices that cannot access all of the addressable + memory. For many years there are better more and robust interfaces to get + memory with DMA specific requirements (:ref:`DMA API <_dma_api>`), but + ``ZONE_DMA`` and ``ZONE_DMA32`` still represent memory ranges that have + restrictions on how they can be accessed. + 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 on 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 the contents of most pages in ``ZONE_MOVABLE`` is + movable. That means that while virtual addresses of these pages do not + change, their content may move between different physical pages. Often + ``ZONE_MOVABLE`` is populated during memory hotplug, but it may be + also populated on boot using one of ``kernelcore``, ``movablecore`` and + ``movable_node`` kernel command line parameters. See :ref:`Page migration + ` and :ref:`Memory Hot(Un)Plug <_admin_guide_memory_hotplug>` + 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``. + +It is important to note that many kernel operations can only take place using +``ZONE_NORMAL`` so it is the most performance critical zone. Zones are +discussed further in Section :ref:`Zones `. + +The relation between node and zone extents is determined by the physical memory +map reported by the firmware, architectural constraints for memory addressing +and certain parameters in the kernel command line. + +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 | + +---------+----------+-----------+ +------------+-------------+ + +.. _nodes: + +Nodes +===== + +As we have mentioned, each node in memory is described by a ``pg_data_t`` which +is a typedef for a ``struct pglist_data``. When allocating a page, by default +Linux uses a node-local allocation policy to allocate memory from the node +closest to the running CPU. As processes tend to run on the same CPU, it is +likely the memory from the current node will be used. The allocation policy can +be controlled by users as described in +Documentation/admin-guide/mm/numa_memory_policy.rst. + +Most NUMA architectures maintain an array of pointers to the node +structures. The actual structures are allocated early during boot when +architecture specific code parses the physical memory map reported by the +firmware. The bulk of the node initialization happens slightly later in the +boot process by free_area_init() function, described later in Section +:ref:`Initialization `. + + +Along with the node structures, kernel maintains an array of ``nodemask_t`` +bitmasks called ``node_states``. Each bitmask in this array represents a set of +nodes with particular properties as defined by ``enum node_states``: + +``N_POSSIBLE`` + The node could become online at some point. +``N_ONLINE`` + The node is online. +``N_NORMAL_MEMORY`` + The node has regular memory. +``N_HIGH_MEMORY`` + The node has regular or high memory. When ``CONFIG_HIGHMEM`` is disabled + aliased to ``N_NORMAL_MEMORY``. +``N_MEMORY`` + The node has memory(regular, high, movable) +``N_CPU`` + The node has one or more CPUs + +For each node that has a property described above, the bit corresponding to the +node ID in the ``node_states[]`` bitmask is set. + +For example, for node 2 with normal memory and CPUs, bit 2 will be set in :: + + node_states[N_POSSIBLE] + node_states[N_ONLINE] + node_states[N_NORMAL_MEMORY] + node_states[N_MEMORY] + node_states[N_CPU] + +For various operations possible with nodemasks please refer to +``include/linux/nodemask.h``. + +Among other things, nodemasks are used to provide macros for node traversal, +namely ``for_each_node()`` and ``for_each_online_node()``. + +For instance, to call a function foo() for each online node:: + + for_each_online_node(nid) { + pg_data_t *pgdat = NODE_DATA(nid); + + foo(pgdat); + } + +Node structure +-------------- + +The nodes structure ``struct pglist_data`` is declared in +``include/linux/mmzone.h``. Here we briefly describe fields of this +structure: + +General +~~~~~~~ + +``node_zones`` + The zones for this node. Not all of the zones may be populated, but it is + the full list. It is referenced by this node's node_zonelists as well as + other node's node_zonelists. + +``node_zonelists`` + The list of all zones in all nodes. This list defines the order of zones + that allocations are preferred from. The ``node_zonelists`` is set up by + ``build_zonelists()`` in ``mm/page_alloc.c`` during the initialization of + core memory management structures. + +``nr_zones`` + Number of populated zones in this node. + +``node_mem_map`` + For UMA systems that use FLATMEM memory model the 0's node + ``node_mem_map`` is array of struct pages representing each physical frame. + +``node_page_ext`` + For UMA systems that use FLATMEM memory model the 0's node + ``node_page_ext`` is array of extensions of struct pages. Available only + in the kernels built with ``CONFIG_PAGE_EXTENTION`` enabled. + +``node_start_pfn`` + The page frame number of the starting page frame in this node. + +``node_present_pages`` + Total number of physical pages present in this node. + +``node_spanned_pages`` + Total size of physical page range, including holes. + +``node_size_lock`` + A lock that protects the fields defining the node extents. Only defined when + at least one of ``CONFIG_MEMORY_HOTPLUG`` or + ``CONFIG_DEFERRED_STRUCT_PAGE_INIT`` configuration options are enabled. + ``pgdat_resize_lock()`` and ``pgdat_resize_unlock()`` are provided to + manipulate ``node_size_lock`` without checking for ``CONFIG_MEMORY_HOTPLUG`` + or ``CONFIG_DEFERRED_STRUCT_PAGE_INIT``. + +``node_id`` + The Node ID (NID) of the node, starts at 0. + +``totalreserve_pages`` + This is a per-node reserve of pages that are not available to userspace + allocations. + +``first_deferred_pfn`` + If memory initialization on large machines is deferred then this is the first + PFN that needs to be initialized. Defined only when + ``CONFIG_DEFERRED_STRUCT_PAGE_INIT`` is enabled + +``deferred_split_queue`` + Per-node queue of huge pages that their split was deferred. Defined only when ``CONFIG_TRANSPARENT_HUGEPAGE`` is enabled. + +``__lruvec`` + Per-node lruvec holding LRU lists and related parameters. Used only when + memory cgroups are disabled. It should not be accessed directly, use + ``mem_cgroup_lruvec()`` to look up lruvecs instead. + +Reclaim control +~~~~~~~~~~~~~~~ + +See also :ref:`Page Reclaim `. + +``kswapd`` + Per-node instance of kswapd kernel thread. + +``kswapd_wait``, ``pfmemalloc_wait``, ``reclaim_wait`` + Workqueues used to synchronize memory reclaim tasks + +``nr_writeback_throttled`` + Number of tasks that are throttled waiting on dirty pages to clean. + +``nr_reclaim_start`` + Number of pages written while reclaim is throttled waiting for writeback. + +``kswapd_order`` + Controls the order kswapd tries to reclaim + +``kswapd_highest_zoneidx`` + The highest zone index to be reclaimed by kswapd + +``kswapd_failures`` + Number of runs kswapd was unable to reclaim any pages + +``min_unmapped_pages`` + Minimal number of unmapped file backed pages that cannot be reclaimed. + Determined by ``vm.min_unmapped_ratio`` sysctl. Only defined when + ``CONFIG_NUMA`` is enabled. + +``min_slab_pages`` + Minimal number of SLAB pages that cannot be reclaimed. Determined by + ``vm.min_slab_ratio sysctl``. Only defined when ``CONFIG_NUMA`` is enabled + +``flags`` + Flags controlling reclaim behavior. + +Compaction control +~~~~~~~~~~~~~~~~~~ + +``kcompactd_max_order`` + Page order that kcompactd should try to achieve. + +``kcompactd_highest_zoneidx`` + The highest zone index to be compacted by kcompactd. + +``kcompactd_wait`` + Workqueue used to synchronize memory compaction tasks. + +``kcompactd`` + Per-node instance of kcompactd kernel thread. + +``proactive_compact_trigger`` + Determines if proactive compaction is enabled. Controlled by + ``vm.compaction_proactiveness`` sysctl. + +Statistics +~~~~~~~~~~ + +``per_cpu_nodestats`` + Per-CPU VM statistics for the node + +``vm_stat`` + VM statistics for the node. + +.. _zones: + +Zones +===== + +.. admonition:: Stub + + This section is incomplete. Please list and describe the appropriate fields. + +.. _pages: + +Pages +===== + +.. admonition:: Stub + + This section is incomplete. Please list and describe the appropriate fields. + +.. _folios: + +Folios +====== + +.. admonition:: Stub + + This section is incomplete. Please list and describe the appropriate fields. + +.. _initialization: + +Initialization +============== + +.. admonition:: Stub + + This section is incomplete. Please list and describe the appropriate fields.