From patchwork Fri Jan 13 11:12:11 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mel Gorman X-Patchwork-Id: 13100523 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 15729C54EBE for ; Fri, 13 Jan 2023 11:12:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78E788E0002; Fri, 13 Jan 2023 06:12:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 73E378E0001; Fri, 13 Jan 2023 06:12:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62CDA8E0002; Fri, 13 Jan 2023 06:12:31 -0500 (EST) 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 54D028E0001 for ; Fri, 13 Jan 2023 06:12:31 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 110B6A0178 for ; Fri, 13 Jan 2023 11:12:31 +0000 (UTC) X-FDA: 80349512502.08.59FDC2F Received: from outbound-smtp30.blacknight.com (outbound-smtp30.blacknight.com [81.17.249.61]) by imf19.hostedemail.com (Postfix) with ESMTP id 848341A0004 for ; Fri, 13 Jan 2023 11:12:29 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.61 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673608349; 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=4OVqnDrxBC309ljmSktuxy8fSvNEHvAFGZQQGyvJuPA=; b=Qy9rrL4/tHN8bbOhexyg5Icy+GJMbWCOYZmMeeLERjNY5SdeBde8l/e4KPEB8mg0Z2jMJh SVXhD+8Ogr6uKfJWQgkHhW3MOeRGvQt7DVFUMefpB+EptjX8se8oQHs9moL+tZ80BNKVjY LKBfGs32CR4CMZys4ShBHpg1d5poYo0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.61 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673608349; a=rsa-sha256; cv=none; b=BTcvVvLLmfd7/fl7hAvRwsiWSyK5ItvPFhzDrZqQ+H6tliYd6owboC5r5apsUXauL3LCtA EWIMUee5ab3bYYqUl6TxdYTWrNBfVHmQ0W+j8AwsXShCQYkDab69OWrA225KuZRoyb5gC3 66I4yL9Z2sYzlw2kDraa6gRgVt466rM= Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp30.blacknight.com (Postfix) with ESMTPS id 3754518027 for ; Fri, 13 Jan 2023 11:12:28 +0000 (GMT) Received: (qmail 8319 invoked from network); 13 Jan 2023 11:12:28 -0000 Received: from unknown (HELO morpheus.112glenside.lan) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPA; 13 Jan 2023 11:12:27 -0000 From: Mel Gorman To: Andrew Morton Cc: Michal Hocko , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , Linux-MM , LKML , Mel Gorman Subject: [PATCH 0/6 v3] Discard __GFP_ATOMIC Date: Fri, 13 Jan 2023 11:12:11 +0000 Message-Id: <20230113111217.14134-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: z7fno3rjnf38zqn4ne8t14mooc9eomd7 X-Rspamd-Queue-Id: 848341A0004 X-HE-Tag: 1673608349-17009 X-HE-Meta: U2FsdGVkX18vVUpo37I/B7gjr+WiwMoZxPAXnNh5zrQF2d8XSukb7OlrfPSMV4aL9APzW7Z4ImuLJZ6DtMjTToLonmntRdwD+z2HglIImHeEaMn/hmNu0wrZWT9j4TRNH/oD/Jqxv/bLx1ZnuVzvLr2WDaH6P9QSc9mxrOgL4w04IqDI2AleOO0RT28Vf85xl58A3WKfGp6c2kMyziFxywioAtcdb3D7Ri0iKtJuZiAjF9UMDEKg/qQrMEI8VTQPx/IgNxoxlFVHZhPUeWu7CyigqgvZs6ecwdQzb1fsFtC4JDuz+barNhOuLoLcZjBSJuV3hC6acb7y+CRm/dIovgostnGa/Lekvab4zXeOz8+4zLGr/Ie2UQdQdtGbXl0xQcXxA4SJueKn2YUvrslNJSRXGNtx/o/Gsdq6gP8r4YRa/qRRA7gtV5RDaVIQPzZqRxYycoNDDf5yngSm+4lS/NCi0fYJP8kLFnG/8r7HnF7Uuf2FPFYXkVCf7NK9GL16I2deuaTiPCIugsR1nMuiTIVbXmryX3AdIGojtmGmAePgNVE6KkV4bHoUqqQudwcGXKQ2z9gAXtIqGoHRKRMnEgS6LjTvJXVWBTQKqFGllff8igQxyjR/3k/73Vyh+ESYP1e2+JZLTEc9ANvyO4hOvo83nu3T7YKBtaiRh1t8kc19WgG9LJwFs3xHrZJohRUfXisMgOq6pe4Fm4Nxm73cHl1YnVf6bswS9pAIjyKPqWEiKK4ZbllR4JB/cEHNzZU1JX5T2S7FIfKzkKzjyPCN/yeToeINGNiWFVKs8DfADUajXfQfzVkc0DckWuZssFNzU4oQDRJ8mbodPncXPmqxBgu9jFrMQjyFHGTQzYSa5eadIdXp8LvkVtwtfEViSG71kWPnyHEq1BBhEVsoLBNtCL9JrZk11Phi7q58O3/M2G/FgAEq1fqMiWzs0rFQd3ZSLyjqnsIaIML4RpBzmHo FUwEqKap gVgFezUrqdiQOLOEmeKNN7Lqrh13qwbSxjuK3coAYoW1R8Dg6gaTX4U4BEG2mlmhhvqSI 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: This replaces the "Discard __GFP_ATOMIC v2" series in mm-unstable. There are changelog and patch replacements that make -fix patches impractical. Changelog since v2 o Non-blocking (GFP_NOWAIT) allocations get no reserve access (mhocko) o __GFP_NOFAIL before OOM reserve access reduced (mhocko) o Changelog clarifications (mhocko) o Note that rt_task treatment to be deleted in changelog (mhocko) o One ack dropped as the patch changed enough to invalidate it 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 | 106 ++++++++++++++++++++------------- tools/perf/builtin-kmem.c | 1 - 8 files changed, 88 insertions(+), 61 deletions(-)