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 4EB4BC77B61 for ; Fri, 28 Apr 2023 10:41:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C34A66B0071; Fri, 28 Apr 2023 06:41:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE4406B0072; Fri, 28 Apr 2023 06:41:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD3086B0074; Fri, 28 Apr 2023 06:41:57 -0400 (EDT) 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 9EA616B0071 for ; Fri, 28 Apr 2023 06:41:57 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5EBB380375 for ; Fri, 28 Apr 2023 10:41:57 +0000 (UTC) X-FDA: 80730459474.30.A71CCA1 Received: from outbound-smtp18.blacknight.com (outbound-smtp18.blacknight.com [46.22.139.245]) by imf18.hostedemail.com (Postfix) with ESMTP id 21E031C0003 for ; Fri, 28 Apr 2023 10:41:54 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf18.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.245 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=1682678515; 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=/JyNkif/SOknKBP5GvnwBgP2yE+8okMXm07sjMJqPXU=; b=qi2GKqc8hgE8UlefifgDvXYnuYD/WtXtjx5+BgacLPhj0pKIt+1OXFh0cC4QlhJ9MZm59k LvZ/sPcsQJnps/JhlEnTz9ZCGorzF1BPxz4Jf1gsU8nceTbKlzSPkvGAGyoG+kTCvzZZje kko6iWNEJbR8KytyXzx9CGCGxjDlwvE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf18.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.245 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682678515; a=rsa-sha256; cv=none; b=y8AKrmMVhjx+w8dJwsuP8rk8oRcIZifaEK0WewqlsBVl7KwyFwstHRGDA+4EobeCWwZsLy vv9ps+yUIYHxBu37DPGJwQw+spQ9wu4LAKG+Yk9Uv7RipDjVHFy0bZS68nnGjaQuL2bspC +arW/X+DPS17h8YWfIffeMxpUO1OKmc= Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp18.blacknight.com (Postfix) with ESMTPS id 1A4611C41F3 for ; Fri, 28 Apr 2023 11:41:53 +0100 (IST) Received: (qmail 32649 invoked from network); 28 Apr 2023 10:41:52 -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); 28 Apr 2023 10:41:52 -0000 Date: Fri, 28 Apr 2023 11:41:51 +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: <20230428104151.tau2mru65rdsisyg@techsingularity.net> References: <20230418191313.268131-1-hannes@cmpxchg.org> <20230418191313.268131-11-hannes@cmpxchg.org> <20230421141447.2cw5cfwibb7jxf6n@techsingularity.net> <20230425154026.GC17132@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230425154026.GC17132@cmpxchg.org> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 21E031C0003 X-Stat-Signature: s43sx46jn3k9pzad13q8t13yk1nm7ccm X-Rspam-User: X-HE-Tag: 1682678514-588052 X-HE-Meta: U2FsdGVkX19b0asAAO0d4E/OwaWHZ6Psr496OL9kMa/XaqsxjSpMEiSzoSq2Q8y5PD2yvE4IT7mwN8lVSNCoqnOl2NlG8a44h5N0u9iU93wgc7ki7xxW4lxp7VGC6JLluMlvOmz2lji77hdi50TQLfzfc3HVpIeSvibdGI53gFcn8seIjY1HEj4Fme4Tanup2HIOY7LHyA+xFimWa+FDBK0DA/klOPskE7DcRtThLGt3NaTCczukgqh/0EwVC0vukHypSkSmo2pDStK9UmnxTLbpEFIh49+J+9Pxnr/hpaZ4I6pobBc5RucY4Qs+MusR0ZniIvIQFRlArOEUf86W8sZ3XgEUu+iO+olgy5KTTDR7GISErKBzH1S+W9oanImxl3uGwSxsYTHJ8PtyaXH1TeeZ1gZ04TZEEkOSjmz7Q6WvNrLLcEsRRdPcE5JO9X41FffL7qTWe4rYzTkEXVY6jre2wkTTLgpGqvrMKaaiLA2KZcrxWjj8USAcGwW4F8FrQSp5Lj1cvCV+hkLnaW73MiSfmgv93PVMvCXYFZztZm+x7Kx8T9lXCygSOA5AMFh6XO8pnHWJxJDMK0JBeXdpGeUfpN7sThzsa21HCTNeIl3wavCdkbDL7b5duIhHaatbQhxR+Rn6NivZDU/z+f6L6fg72n+1Q2Wt0wBN+YcFz5I29NB0xr57cqhu2r+UAF3Gee7Fai/gxntWHZgdnrkKrt1aWkxr0GoBAh4Lw8geNA+6puP1DkHXyqU1W4guuyikVn9Tu7nTieqmbsaSRZJVm1KMsGf1OiCnAzpQD0ySkuHfEse+f5sab0DplelMuppwixlFutsBIb22aBd3rnlTc0nt8LFml1zFYh8XrxF9QkuzuuISy0+KizPmKJYpM2lCMbbbzsAPoBXfqFos7C3n+kqaXlwACd2tKt+utqPVeN4wtFFX72G9YyU0oB32zDIq95tzrIQHiBWbmCDPNH7 MP943VY7 7IOd+rlfDDEUwq+E5cgnHbyKlP2aYhSRdVuJ2ZQw0GZLXwFOj0Qgbv4SUt8z7xGaVPO4a43Fr3hapbmmir//qA2wEhhgtiePe36QqcafX5rDcpRm/mNeHqUJKGHyRrzVY1nA3vZN2vQY1O4vP4IaAG+zO3JtHaAN5ccTVjFmT58GieSuIARUEvB++/dOCsf5Crqx9uk1TNdmYiTPMnwTcjUKp01+EWcspgJzLNDf38I7QJSbn3/AwDlHkbTBjP3Vi0RqeRb39gPj6WfSO8R4hL6Scuw== 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 25, 2023 at 11:40:26AM -0400, Johannes Weiner wrote: > On Fri, Apr 21, 2023 at 03:14:47PM +0100, Mel Gorman wrote: > > 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. > > Looking at this patch independently, once merging continues to the > full block, a fallback would be allowed to claim it anyway > (can_steal_fallback() returns true). I don't quite see a downside > letting capture apply in this case. The plus is of course avoiding the > indirection through the freelist which risks an opportunist request of > a smaller order fragmenting the block and wasting the contiguity work. > > In the context of the full series, this becomes even more > important. Once watermarks are required to be met in MIGRATE_FREE > blocks, and reclaim/compaction recycle full blocks, merging up to > pageblock_order happens all the time - and needs to happen for > allocations to succeed. This applies to all types of direct reclaim: > unmovable request freeing reclaimable/movable blocks, reclaimable > freeing movable blocks, movable freeing reclaimable blocks. > > I see your point about smaller orders now always ending the merge at > the pageblock, even when there could be additional merging > opportunities beyond. However, I'm not sure these accidental larger > merges beyond what's needed to fulfill the request at hand are a > preferable aspect over reclaimer fairness, and thus ultimately the > reliability of orders up to the pageblock size. > > I'll try to get some numbers for this patch independently, though. > This should manifest in p99 allocation latencies and near-OOM > behavior. Is there anything else you'd want me to look for? > Any major change in the number of the mm_page_alloc_extfrag trace event triggering. Also put the patch at the end of the preparation series of possible or even do it as a separate follow-up patch after the bulk of the series has been handled. While I cannot 100% convince myself either way, I wonder if variable high-order allocation requests smaller than a pageblock could cause premature mixing due to capture. -- Mel Gorman SUSE Labs