From patchwork Fri Feb 28 09:52:18 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brendan Jackman X-Patchwork-Id: 13996061 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 0ABEBC282C5 for ; Fri, 28 Feb 2025 09:52:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F6996B0092; Fri, 28 Feb 2025 04:52:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8632E6B0093; Fri, 28 Feb 2025 04:52:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6857F280001; Fri, 28 Feb 2025 04:52:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3C6326B0092 for ; Fri, 28 Feb 2025 04:52:28 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E6FE24BFA9 for ; Fri, 28 Feb 2025 09:52:27 +0000 (UTC) X-FDA: 83168888334.18.04BE8E1 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) by imf23.hostedemail.com (Postfix) with ESMTP id 1E6A4140008 for ; Fri, 28 Feb 2025 09:52:25 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mw8RNQ0c; spf=pass (imf23.hostedemail.com: domain of 3WIfBZwgKCLEaRTbdReSXffXcV.TfdcZelo-ddbmRTb.fiX@flex--jackmanb.bounces.google.com designates 209.85.128.73 as permitted sender) smtp.mailfrom=3WIfBZwgKCLEaRTbdReSXffXcV.TfdcZelo-ddbmRTb.fiX@flex--jackmanb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740736346; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HO3rm5+cQOMI85a/kqJJUn+V+LGjTUrNi05UBywCRJg=; b=QJ1wy4S8707TZQgBBTjPmmRBgmt/iYmicplldQ/uleRBCt4A52RPiIxJJ+05xwoX9rO9Pg FTurqtmOFnCEzblahluW0l0/UCZsWD1pVMI1w73nQYufH4T+yvlaFoLtuBWlVHspyGFIdS KqJjlkBx5uF3jL6P6mt2bluSkYVuJlY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mw8RNQ0c; spf=pass (imf23.hostedemail.com: domain of 3WIfBZwgKCLEaRTbdReSXffXcV.TfdcZelo-ddbmRTb.fiX@flex--jackmanb.bounces.google.com designates 209.85.128.73 as permitted sender) smtp.mailfrom=3WIfBZwgKCLEaRTbdReSXffXcV.TfdcZelo-ddbmRTb.fiX@flex--jackmanb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740736346; a=rsa-sha256; cv=none; b=NGVF/vCDRECidgY3CtPIeJuJiaazjq0OC/0B6+eniRAX3budq3RZilZPxnOtNSaEzEBDH/ 0Tm2Poctwrx04P0LH4DiPjiu5MzajREGw6MxZ9nH/gMSUnD4jSfII+teH4Ca+6IsdWlhEM 5+IJzk+soJH5koY6mnKFQUJjC4CNrM8= Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-4394b8bd4e1so10175245e9.0 for ; Fri, 28 Feb 2025 01:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740736344; x=1741341144; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=HO3rm5+cQOMI85a/kqJJUn+V+LGjTUrNi05UBywCRJg=; b=mw8RNQ0c7umzVbvnw7qgBzP0v3UGnEAGteEHTl8vLQgrxWzOVN8pCW5U9ZZlG1Gbna XGek/twG3XoBiRenz9WaEigyGssUTsD83aBn/jlVhgeZu3kVKiCdSmyBD88scnWmCGr6 vRFykvUTSbeGmsqbz47Yq80PiY9k8mMeEOPq2vfnkdt/QEl/5GDuJDyk8CwWuyCqiO4n 4S9P9SKKyMhjhc3X6kXbU+fdgwkNLO7AKKz8AJVaVtntmKkWw8iWbM+z1v+An6dJfQYo Q5VdOx6jrggurvDvNtbSEJg6W2lty3zyizBt1rLnotAlJdNRPts5O8+ywHTjykKQGgMP AhPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740736344; x=1741341144; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HO3rm5+cQOMI85a/kqJJUn+V+LGjTUrNi05UBywCRJg=; b=BJ4XDD51ORdvJeFWhH7j982lCMzyfRVL4ddev7IUuKWYcsc3OSqP50zOzT7YpEOHY5 cYzHrvX2eeuAe8w2FTJPNWci5HE068qlL5f5FZ9lGWFysqyZB0x76gbUfUDd4YAxx9bT OnUx5XeRzaqE1aXJ8Hwy03MQS0mGg1t3/GbCfcRwRkjAPRBFzDbQA508Rh/mH/dg35mM bcmQoPhOM57K8wYeAdUaX/i2fXo1ERlaoi0Gb1f0BK2hoiqeQ8IY2o58UzGbEDFa6R51 Ns3137LBXFCBlxi5cm7zbrzSxV9SsMzmyltguzf2cJ4mQrUVxb+TLZy+puEjTpEhkBQb 4+yA== X-Forwarded-Encrypted: i=1; AJvYcCV6kaip+Y3B9O+3u499hqCy7F8JRprF+Dt58fdTu1OcbpbhzNsJ8Jt1jq9yl6XyBY0Uv8XDlEqqjQ==@kvack.org X-Gm-Message-State: AOJu0Yw4plYR0g+cU/DGWollPDPFLHHQTWddLS5wYZOQJRElc98Yf+zn UloamQbuvitNUrLEEMIyE4uQ4fg/cM02bWMGDJ37y4ChlS1o4cgaoum7Kgrsd4X8hgOzO1eRGQm k4ISslz6n9g== X-Google-Smtp-Source: AGHT+IE1A0Dj6yDwVQ5f1BronRrhiqIk/3BQtEj5r1ew6jfrtBzSUFcUVO/MsKCaxzJF66E3L65r+gpQTCtWGQ== X-Received: from wmbbh18.prod.google.com ([2002:a05:600c:3d12:b0:439:8e3e:b51b]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:190a:b0:439:9c0e:3709 with SMTP id 5b1f17b1804b1-43ba66e6b0emr22738525e9.8.1740736344709; Fri, 28 Feb 2025 01:52:24 -0800 (PST) Date: Fri, 28 Feb 2025 09:52:18 +0000 In-Reply-To: <20250228-clarify-steal-v4-0-cb2ef1a4e610@google.com> Mime-Version: 1.0 References: <20250228-clarify-steal-v4-0-cb2ef1a4e610@google.com> X-Mailer: b4 0.15-dev Message-ID: <20250228-clarify-steal-v4-2-cb2ef1a4e610@google.com> Subject: [PATCH v4 2/2] mm/page_alloc: Clarify should_claim_block() commentary From: Brendan Jackman To: Andrew Morton Cc: Vlastimil Babka , Mel Gorman , Michal Hocko , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Brendan Jackman , Yosry Ahmed X-Rspam-User: X-Stat-Signature: p1drm99xofhbowsge9yu5f63q76oy3df X-Rspamd-Queue-Id: 1E6A4140008 X-Rspamd-Server: rspam07 X-HE-Tag: 1740736345-534978 X-HE-Meta: U2FsdGVkX18x5G8cdwO0/I+rI84se8JHo8ePK9MRWNmONvTx25CWvXvmnKxlvSwlji9G9nltLwe860vzhekRuFf3aELCaZO6sUZlrPOR0ecYwlspaHqHSB82TvrSuGLhPUrUboM7IALa7nwrntihfgZzsFQaRIAlWOuiO+dQ08iOxnSWXPGZSQ8wbponY41yz0Em01EsY1doQsCxhVypYOVxOUOlzOUh/2YoxrzpPu+I47ohq6OoUyK/srszsskrKbrFuWVqKS7DTcSWaCYe6VbUF/8eXeAwTwGFI3Ehod9ZtsEBp2ncOFTmEKHcW6As1EXdKegk9tM6yZXIOe4I9VCryMtXrTcMybCXE0s5g4qu9q5mQ9//w0tCi4G+cqKGRxYPUJOWEyYHBAdGGxVYz/08HjFY6IzEvcN7aAZlHaegh7uC97tZrHpyqDjKcbBkcojFvNBIWuknBIddRHNj2SUNPTE+IHU1LMfiiwzyzwQlDtLG4AYHotvrNLkTK5IRSTrqZCtMJp6iT+bZpWjiRWBpYuAscPwc0LOORhc0PGNd57mWmu/6XfcNoE7Go4l8rZvuU+QSxa07ZQKanAFwXzHqgAd57OBoiGOnBGdcELHgW0fmalsVsdfduAM7ddG4xwJVesO675nvqW6LNV0vs+pwFweFSQqZi5MGJP2I8uGgHu7Ztjn0Nc1LQ0pD2Bf0ayZ/fwHBpdlaG80Kayeakeshfu8IBBbKxvXTnUhwEMKCY8Dqm+tIgdkWHxX6+/+t1X5HyjrNPoVWFVB/jfLv4ETOJfCvBm6cFhEhB84frCQ6sn287ZyiEBrjw2fdHpM+I9APDjvNXJA1euS+vFu277lZL9KBerDrKhBpjdCCZtO0ruSqD3jBq1i5vZR1DK+yN5V2bGca1ogHyqJgk6Y4fMcPOHjZuv4YoD+D8Lc5J0f/C9RtSTYGAYuVn+apZT/uKmZ5VZVKcoqtfjOKrOh aOWvPiZo ShdOH9QDT2xGsgH93Sh4iaptnKS/jg2O6J1B8Sjym6w8WCTe5oI50Fg1O/KBduN5bPo+V8IBiKx1uPr6YO9IAC7/hvLzMrWgMbNx9nqV3/qT5ITy02sfxVfaGe6mkVEgkk8b6rq6bIRxlEr9jwZyRoRFaPSYqWuhuBp+Aj0jfAxpEz3C86Xx58emIVL2UOjktAlwgYBJyQ1jDnyBKdZIHuSZ1KAFAtGX9RVdrTqmnVH4Q+lLYKcoiH9uGnCGAMeHcaCzPAQRBWhT2/Fsx6sG1VGnhi10bH0CVHPML177YM4QGkrSvbnB6kEUuruXDGaqwASj5PuKjV6yhY0Noi+ZrYKnCNBd2QZNUudMbWqabXZNYHeJHIbPojh+8MGZv0wnsEnvBLzol9ROA36SIvVDxSOgmtPxxJhkMumuFu1/p25efjbKPjCzl2oKJ3J1sum9KadGRzRaiUv/kt7aeCEYErlCplAQxIMI8iqKqN2rF6d+MKimFKgEOWTmxA/MgZE0kpCD499HL5PS6YPh7NBAnQEXBc/ojCMQ+pJq2YX0blSTz+Tv0beZJE9UI5vx8V333J1KInjKCNJSsEHKVqcUXTNHEgJHlAab12O+7 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: There's lots of text here but it's a little hard to follow, this is an attempt to break it up and align its structure more closely with the code. Reword the top-level function comment to just explain what question the function answers from the point of view of the caller. Break up the internal logic into different sections that can have their own commentary describing why that part of the rationale is present. Note the page_group_by_mobility_disabled logic is not explained in the commentary, that is outside the scope of this patch... Signed-off-by: Brendan Jackman Reviewed-by: Vlastimil Babka --- mm/page_alloc.c | 46 ++++++++++++++++++++++++++-------------------- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 441c9d9cc5f8edbae1f4169207f5de9f32586f34..17ba5d758aa539370947b6f894e5fce7de6c5c5e 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1941,16 +1941,9 @@ static inline bool boost_watermark(struct zone *zone) } /* - * When we are falling back to another migratetype during allocation, try to - * claim entire blocks to satisfy further allocations, instead of polluting - * multiple pageblocks. - * - * If we are stealing a relatively large buddy page, it is likely there will be - * more free pages in the pageblock, so try to claim the whole block. For - * reclaimable and unmovable allocations, we try to claim the whole block - * regardless of page size, as fragmentation caused by those allocations - * polluting movable pageblocks is worse than movable allocations stealing from - * unmovable and reclaimable pageblocks. + * When we are falling back to another migratetype during allocation, should we + * try to claim an entire block to satisfy further allocations, instead of + * polluting multiple pageblocks? */ static bool should_try_claim_block(unsigned int order, int start_mt) { @@ -1965,19 +1958,32 @@ static bool should_try_claim_block(unsigned int order, int start_mt) return true; /* - * Movable pages won't cause permanent fragmentation, so when you alloc - * small pages, you just need to temporarily steal unmovable or - * reclaimable pages that are closest to the request size. After a - * while, memory compaction may occur to form large contiguous pages, - * and the next movable allocation may not need to steal. Unmovable and - * reclaimable allocations need to actually claim the whole block. + * Above a certain threshold, always try to claim, as it's likely there + * will be more free pages in the pageblock. */ - if (order >= pageblock_order / 2 || - start_mt == MIGRATE_RECLAIMABLE || - start_mt == MIGRATE_UNMOVABLE || - page_group_by_mobility_disabled) + if (order >= pageblock_order / 2) return true; + /* + * Unmovable/reclaimable allocations would cause permanent + * fragmentations if they fell back to allocating from a movable block + * (polluting it), so we try to claim the whole block regardless of the + * allocation size. Later movable allocations can always steal from this + * block, which is less problematic. + */ + if (start_mt == MIGRATE_RECLAIMABLE || start_mt == MIGRATE_UNMOVABLE) + return true; + + if (page_group_by_mobility_disabled) + return true; + + /* + * Movable pages won't cause permanent fragmentation, so when you alloc + * small pages, we just need to temporarily steal unmovable or + * reclaimable pages that are closest to the request size. After a + * while, memory compaction may occur to form large contiguous pages, + * and the next movable allocation may not need to steal. + */ return false; }