From patchwork Mon Jan 9 15:16:24 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mel Gorman X-Patchwork-Id: 13093707 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 33919C54EBD for ; Mon, 9 Jan 2023 15:16:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B33258E0009; Mon, 9 Jan 2023 10:16:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE32F8E0001; Mon, 9 Jan 2023 10:16:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D26F8E0009; Mon, 9 Jan 2023 10:16:47 -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 8F3068E0001 for ; Mon, 9 Jan 2023 10:16:47 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4FC5180705 for ; Mon, 9 Jan 2023 15:16:47 +0000 (UTC) X-FDA: 80335612854.13.B3CE079 Received: from outbound-smtp43.blacknight.com (outbound-smtp43.blacknight.com [46.22.139.229]) by imf24.hostedemail.com (Postfix) with ESMTP id 9BCB218000F for ; Mon, 9 Jan 2023 15:16:45 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.229 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673277406; 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; bh=0AmY71UyNWLVxnWmBBitB7lJMcyRbrVL3L3ELFNbV/c=; b=lLZsJov8c/5A7h0fVfW8JtEvkWYSnj3ItnYUO4KmIyeWHhyvtynskSVD/m/q0dsswlODML lGG+4qLEDQyfxop1d4xHcvQHxeWELegn1/8hXuOPiWxCpfGfcCUJMVFfFA3vdXeSDInJYj 8DotD2EEccse2rAJPr2PDXikLDBzZGM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.229 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673277406; a=rsa-sha256; cv=none; b=Rb6v5sHgynMmaXKNzfi5aExgEVRrMj4SKVlVhyW76Xz4d/U5/zi8SnPYFPV+iYmlGj6t+a jj/RiixsOzgS0g+RGKFKtXV5jX0sdA/lhYIWon7nwzVsF+gfX6LXW9liBa6bPcUbQls9jr qU/3fVQkystzeSDc0omOHKV59I/+5wg= Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp43.blacknight.com (Postfix) with ESMTPS id E79851FA6 for ; Mon, 9 Jan 2023 15:16:43 +0000 (GMT) Received: (qmail 15870 invoked from network); 9 Jan 2023 15:16:43 -0000 Received: from unknown (HELO morpheus.112glenside.lan) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPA; 9 Jan 2023 15:16:43 -0000 From: Mel Gorman To: Linux-MM Cc: Andrew Morton , Michal Hocko , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML , Mel Gorman Subject: [PATCH 0/6 v2] Discard __GFP_ATOMIC Date: Mon, 9 Jan 2023 15:16:24 +0000 Message-Id: <20230109151631.24923-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9BCB218000F X-Stat-Signature: 8is1gt8dyi1a4od9mf1ztiqjtnkxm6ba X-HE-Tag: 1673277405-65492 X-HE-Meta: U2FsdGVkX19mazQwvkWbuApUeDznEraR8i5h3JiYdTRqnTirL2//aqL9/ofQMspaWnsSsNmX4jVKuQXut1RCxlDRgaWzu9J4NrhZYQbNFLrRQtHLavZZ1QzIvB3lKrdMvl6HUM5SNsUEU3sBiMtEDUSS6jN7hqfgNB14xvrdl3mZNK2hUESB1IofrskZ9yk3Oa4ykyZ01DCNxqHBL9QoSL2XnJ0MTxRsNLrujbCbZuucyYlvmJgi1RpPMlvwzoTUyW+4qd8c5VQG8KLL6P8cGeDG3ZOSz4/Guxcf40IDdNNV+vJYyomIbSboaf9YrZthsyMJU3ft5yrq+q7CCBKA21XM/DE2mKqpMFbSU2NLZ6zM1lLBcj601WkCUDGYjTN5VWXjuX9oAQ8fCf2/2KJv1EFmWMOk4234g6i4zCGi27zgJka3pCqdRKvJfpD5P6D5RLDsLis5nT7615q71Yk2bxZCOpgYuid2UBolFtHxiStpIUyR48luiFT9QbEXRBqlRfYZheyx3KoKziqZ/x1Vdbio49PxnUEsEgraRclJ7B6V2JA2EY6/TxW7Tp6Hex/v0VfJOww4cVIOlN+2L0/6R7q4kbRIc5rwOsI9dZOv9Qk+XkWg1Sd+NP5opSk8mLDuZYcceMVv3i2bM6Q7MXe8Gww9tU30IQKM9N8PKWlin5bwwCmR8dHca7DYSe0VOQC3JTOjPkAR6WyIoHyb5hKl9UU4XWYf9SnUGetDjC0uiV5e0YWWqhlEyQY9bm3pHoT0EVebuhITJtZKnrTU9FKpwxhk9F2f6EEY/irI5O5HuYEwqnKXDFgaQeAgD/U+1irkHLVs3l3um3GLPBDHsNgdJgRLrJ6T06RHKCnlVLf4CWh9CpQdBJYl4iww9GQJdpkjLEfYM7xnMFqkhvBSHbZboWmwWNwN5hR3FfUtFNRG6VRIj4k6dEstm1PqYIz487GaAq6EBmLJorWrtJfCP5j zOXnrjxy TaQqjOe3+rmk0QdgSK+Si/YcrMY0WqwFt4KweUfsM8Y8n11HgUYfBKmuROZ1B55L0DkyV 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: Changelog since v1 o Split one patch (vbabka) o Improve OOM reserve handling (vbabka) o Fix __GFP_RECLAIM vs __GFP_DIRECT_RECLAIM (vbabka) Neil's patch has been residing in mm-unstable as commit 2fafb4fe8f7a ("mm: discard __GFP_ATOMIC") for a long time and recently brought up again. Most recently, I was worried that __GFP_HIGH allocations could use high-order atomic reserves which is unintentional but there was no response so lets revisit -- this series reworks how min reserves are used, protects highorder reserves and then finishes with Neil's patch with very minor modifications so it fits on top. There was a review discussion on renaming __GFP_DIRECT_RECLAIM to __GFP_ALLOW_BLOCKING but I didn't think it was that big an issue and is ortogonal to the removal of __GFP_ATOMIC. There were some concerns about how the gfp flags affect the min reserves but it never reached a solid conclusion so I made my own attempt. The series tries to iron out some of the details on how reserves are used. ALLOC_HIGH becomes ALLOC_MIN_RESERVE and ALLOC_HARDER becomes ALLOC_NON_BLOCK and documents how the reserves are affected. For example, ALLOC_NON_BLOCK (no direct reclaim) on its own allows 25% of the min reserve. ALLOC_MIN_RESERVE (__GFP_HIGH) allows 50% and both combined allows deeper access again. ALLOC_OOM allows access to 75%. High-order atomic allocations are explicitly handled with the caveat that no __GFP_ATOMIC flag means that any high-order allocation that specifies GFP_HIGH and cannot enter direct reclaim will be treated as if it was GFP_ATOMIC. Documentation/mm/balance.rst | 2 +- drivers/iommu/tegra-smmu.c | 4 +- include/linux/gfp_types.h | 12 ++-- include/trace/events/mmflags.h | 1 - lib/test_printf.c | 8 +-- mm/internal.h | 15 ++++- mm/page_alloc.c | 103 ++++++++++++++++++++------------- tools/perf/builtin-kmem.c | 1 - 8 files changed, 86 insertions(+), 60 deletions(-)