From mboxrd@z Thu Jan 1 00:00:00 1970 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 31352C77B71 for ; Fri, 21 Apr 2023 14:14:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF0ED6B0082; Fri, 21 Apr 2023 10:14:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA0ED6B0083; Fri, 21 Apr 2023 10:14:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98F4F6B0085; Fri, 21 Apr 2023 10:14:54 -0400 (EDT) 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 8CB0E6B0082 for ; Fri, 21 Apr 2023 10:14:54 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5D44E1C67DD for ; Fri, 21 Apr 2023 14:14:54 +0000 (UTC) X-FDA: 80705594508.25.6C3AEDA Received: from outbound-smtp35.blacknight.com (outbound-smtp35.blacknight.com [46.22.139.218]) by imf10.hostedemail.com (Postfix) with ESMTP id 6E93EC0018 for ; Fri, 21 Apr 2023 14:14:51 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.218 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=1682086491; 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; bh=yBAprSIdl8RUOcpHJ3jBMFqJq2EB0vneqb3DpOW9e4w=; b=DrqaOYYvMEsnb34X5hH+FwKX8J3hWMUvcmdYymVPbVwsDtyAJzGSAcgLspiTbqAF5LVn21 LC+u1dpzkVb3V2tHDF4xdOrDW8Bh0oQBTTdcMpwtKv089OQ274CuA4IQzP6o4M8ws2VEI1 IFkkiNh9CN94hsA1BQtvdhbxEKNHooA= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.218 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682086492; a=rsa-sha256; cv=none; b=oU2lWiLQ1P9t7irvWjno3OGaV5NJpc30Tx1fCzOTQGNgFOZzZO3rBBnt+JmsdcxFZTjRdx cNQv5ZpD1naxyFObmTifGZCuSQ1eJqSe5Vjo/pDswaxXk1b9hsy1Tk1C49wjNm1tUssFbl bnWy/mP+t0v3BLljoGOY+FbjiqpiLLw= Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp35.blacknight.com (Postfix) with ESMTPS id 9B0FB1FD6 for ; Fri, 21 Apr 2023 15:14:49 +0100 (IST) Received: (qmail 14279 invoked from network); 21 Apr 2023 14:14:49 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.21.103]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 21 Apr 2023 14:14:49 -0000 Date: Fri, 21 Apr 2023 15:14:47 +0100 From: Mel Gorman To: Johannes Weiner Cc: linux-mm@kvack.org, Kaiyang Zhao , Vlastimil Babka , David Rientjes , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [RFC PATCH 10/26] mm: page_alloc: allow compaction capturing from larger blocks Message-ID: <20230421141447.2cw5cfwibb7jxf6n@techsingularity.net> References: <20230418191313.268131-1-hannes@cmpxchg.org> <20230418191313.268131-11-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230418191313.268131-11-hannes@cmpxchg.org> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6E93EC0018 X-Stat-Signature: xfz3sbxn4ijgahhmr8ggrxk77qj1gb9b X-HE-Tag: 1682086491-261695 X-HE-Meta: U2FsdGVkX1+cZjO85GKghDpBRCzKSCXLDE3ifLkKkV9w1Kyrqy04vTFpwJq6Xp3tce3ST9RqjrM/72xGbubzb77bXtoqqnXshNwTNuIsGbpFx7vb1WeN7h11BkZs71p4Ahuy3x2r/prl5PIqmpU8jH0eCZYZQWzFeSdzmyZJ1mXOEXhfmQZOzpi9bR4Ltq0j6aM/wLQUiRK1BQp5Qh40SHmtVgzAqlBohptH3Q9Bx0bPTbms4M7f9gHP5D3ir8UjqCB7SsFfGKHm7PDTeUj4ceew5SAn/VSyjKqdcQTL8Ro+/uSrx/+cwhwDXbiVv9IIsTPBRRG9c4GyWsDcAeNuZ11iCKAhi4VFIdYjMOp6VcgJQKcmZN8iPF69DwgAsw7L2wB8fDI2GQ700BkQ7f33+NSivtqFg8p9l6x/8vhBl8HWFOQt689y7FlCOYbYHpobv7p7AhMtESuTaSVe+ree/TGYhXtLhSYt9horvEhvtxqlWGpty7Lmdq0jRLV85i0Wf/RIBSkcfKEXFAt8u/jn7k+TNtHeB055iEj+IETV7IyqrLohOuxDfKjTEJH3hLuLqQSYjdQKN8qFJzrm3QN4IGayH8szr9XJ7wZmUi38Kr0ayyx6Yj9snEpiX+UYS/k5iZsr5GzDKtUdBAvuVfCViXaUJgXJmy9CPpWzRzH1RIokwfn0WYrQuYmvRr6OTgdR+6+gVPDsRMGT827W2CC/NIfA2hM+0bVjKJXT6S/XHVhWHmS1ymfld2oAfmtJxZ8QFU+/AdI2MWYKsIldltcrvT0UjZeBsSI/HjVnh0KCnJ71F16eD45ZV2+M0tXTRb+Lhty+YUJESjCDhfMTJzTyNwvSacobmuAWmWud3W4FyDGp6b8jVMmd0MoPqN1axIooYTjKTUsLZWc7zKsvQVgM0+g/805MGZtSPZG6318DuozP/skdfBFpp5ykskZLn2K1me1Hp80iZuR906s/rjP y9cpgNAD e1CWNXR0lK6GpQsnYKFUe4zYiAnLK1WzIEhMwIm6/J7DPH7gl1wxYe/H5K+U48yWZJAgAwrJFLO/Tm85zcVyRQV0wwAtHq3I4ZN8XeHNKVtCZGwDgDnGrVDPyB/hzR3IF5rLaThTCL8t9bnRvdW+OvQLNp4f1Yd8ufxuc8HB6irK+uuyyIEpAOaPnM7cKi8IIPsJBPX9XJW011pd4N5iDFly/cyT+lbFl4kH2sE/Ws32odazxAjM4pTpGs58lkffWmcU5sBHjS0Zz0XRaXV9/9/+0qA== 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: On Tue, Apr 18, 2023 at 03:12:57PM -0400, Johannes Weiner wrote: > Currently, capturing only works on matching orders and matching > migratetypes. However, if capturing is initially skipped on the > migratetype, it's possible that merging continues up to a full > pageblock, in which case the migratetype is up for grabs again. > > Allow capturing to grab smaller chunks from claimed pageblocks, and > expand the remainder of the block back onto the freelists. > > Signed-off-by: Johannes Weiner No objections other than we're still in the preparation phase and the series needs to be split. Out of curiousity, how often does this actually trigger in practice? I ask because superficially, I would expect capture to happen while pages are being merged and I'm not sure how much this actually helps. If anything the anomaly would be merging !MOVABLE types, capturing one pageblock and leaving the adjacent block eligible for splitting as UNMOVABLE/RECLAIMABLE which is not necessarily desirable. I nagged about the splitting already but ideally there would be supporting data for all the incremental improvements before a major modification is made to fragmentation avoidance. That way, even if the fragmentation avoidance changes have side-effects, the incremental changes stand alone. -- Mel Gorman SUSE Labs