From patchwork Tue Nov 29 15:16:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mel Gorman X-Patchwork-Id: 13058707 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 B3B3AC4167B for ; Tue, 29 Nov 2022 15:17:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 146476B0071; Tue, 29 Nov 2022 10:17:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F58B6B0072; Tue, 29 Nov 2022 10:17:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F25CC6B0074; Tue, 29 Nov 2022 10:17:16 -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 E6A286B0071 for ; Tue, 29 Nov 2022 10:17:16 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B57BCA0F5F for ; Tue, 29 Nov 2022 15:17:16 +0000 (UTC) X-FDA: 80186833272.18.2219EC1 Received: from outbound-smtp31.blacknight.com (outbound-smtp31.blacknight.com [81.17.249.62]) by imf30.hostedemail.com (Postfix) with ESMTP id D810280019 for ; Tue, 29 Nov 2022 15:17:14 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp31.blacknight.com (Postfix) with ESMTPS id 16087C0C1B for ; Tue, 29 Nov 2022 15:17:13 +0000 (GMT) Received: (qmail 3308 invoked from network); 29 Nov 2022 15:17:12 -0000 Received: from unknown (HELO morpheus.112glenside.lan) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPA; 29 Nov 2022 15:17:12 -0000 From: Mel Gorman To: Linux-MM Cc: Andrew Morton , Michal Hocko , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML , Mel Gorman Subject: [RFC PATCH 0/6] Discard __GFP_ATOMIC Date: Tue, 29 Nov 2022 15:16:55 +0000 Message-Id: <20221129151701.23261-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.62 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669735035; a=rsa-sha256; cv=none; b=YXrj2ZIxrWdnEq/brW244A1VCZKY7zOa0xXXJ2N2dUMp6GXP6G+YyQo73ly51BUtgfXgci CHkfWHYVuKHBxbCVQYdFkcpbuA1clhI9d8nbmeV7z8qDZBfYA4ynlajVzVuI6O+3AD6YqS 8yYM4xiTJ66ZEzvtxdOQpoZcCvJ2LFM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669735035; 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=6kb2S9W4Z/IrS+hkIoCd4bJSxqDhx0SUP3vaYM0FDlo=; b=mVZrXfShr4bx9Jgl6A1/rQZxaO2Vly0lpRWIJWQm6kjM1cKjZ0rtpxLn3C9P7Yee/D5pLi 6oFxU9F2xgOnWpMfZwDiSLprFiYRELgrLKmTh3oWdxx75hiLQvvAewWFlxPn7QrC0UjZyP 9v5pDvffMoxhzFoW7nGACi6CtBeGu7E= Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.62 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net X-Rspamd-Server: rspam01 X-Stat-Signature: ac3cxh1xuwhsmogfmezjj1xhoksgamkx X-Rspamd-Queue-Id: D810280019 X-Rspam-User: X-HE-Tag: 1669735034-440053 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: 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.