Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2080472rwd; Fri, 2 Jun 2023 04:43:45 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4OEPC62cFsGxPVYaxksOIQ+XInfeMCifMKY1kV1czjnYU6OBjDMT6XuAgxoWcrNxXFMGMg X-Received: by 2002:a05:6870:e496:b0:19f:7b5b:2855 with SMTP id v22-20020a056870e49600b0019f7b5b2855mr1929375oag.15.1685706225316; Fri, 02 Jun 2023 04:43:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685706225; cv=none; d=google.com; s=arc-20160816; b=A2g6x0rxYrxQoPXQ8wN9fde7/06m7RA2u7mRjIXAQYqOnVNq8Isbs7KEaqYbpyuspH QR12rtEHhRlyESXEN+V1dL6Fver4HPAr93pDMTFe03AinnbkZJf7raMBf0ehJl1g+860 HeLYD3vBqJMbRwVlte1oIJKcjHjwKnd4LqUEtFu1IQ/emDb4A1pcdndNh9r1aYHukkjd sfLGPAsnOyQTFRRzGRoUvJT2hleQpSAfiOpS3HuAeAwRVVXbfj/JoIjn6hLMth3FTHqC /ZH3b3d3FKEYf9bCpPfHVXNX+CC1usvwba8fJ9tPQmCF2eCEqOsPE3ACP4znn9cxVTdd 59jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=dce/JVD4sxEN5WGytTjHPWW+Q6E+JC7zcSmDdcnYkLc=; b=Q6SivHXcgs5sM274Vziz2IjsydX1i5sxAdHADXG6XbYIQOel/zxANDNaIzID/kDCTT s/xu2L1m068LspCGDBj69YzvmtYG2cXQUmWr9I00HYv0zz6aVM1QaWa7FDxSyHxAhYE6 5TA8e5aFvvqRDyEimMbPzdokdC/eVGED6bocEBAIYFsW45sEJ8oTC1VY6pgCcMyYVcr0 6bsFakDIfXWqHV4WOoqweNkg+SSRBlDk9DzEVLsylt/ambeEPtlGMq9KSSft6+ghc6sP x1VvUgXISgGnREvIVtqpe9Jmv6m0klYoJSfO5uQfKmWkQ+pytSHh/egyVNOcJKIiqOo7 6hvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j24-20020a63cf18000000b005346b8dae84si876144pgg.787.2023.06.02.04.43.31; Fri, 02 Jun 2023 04:43:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235288AbjFBLQa (ORCPT + 99 others); Fri, 2 Jun 2023 07:16:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234562AbjFBLQ3 (ORCPT ); Fri, 2 Jun 2023 07:16:29 -0400 Received: from outbound-smtp35.blacknight.com (outbound-smtp35.blacknight.com [46.22.139.218]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9A55133 for ; Fri, 2 Jun 2023 04:16:26 -0700 (PDT) Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp35.blacknight.com (Postfix) with ESMTPS id 744E91D0B for ; Fri, 2 Jun 2023 12:16:25 +0100 (IST) Received: (qmail 11021 invoked from network); 2 Jun 2023 11:16:25 -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); 2 Jun 2023 11:16:25 -0000 Date: Fri, 2 Jun 2023 12:16:22 +0100 From: Mel Gorman To: Vlastimil Babka Cc: Andrew Morton , Jiri Slaby , Maxim Levitsky , Michal Hocko , Pedro Falcato , Paolo Bonzini , Chuyi Zhou , Linux-MM , LKML Subject: Re: [PATCH 3/4] mm: compaction: Update pageblock skip when first migration candidate is not at the start Message-ID: <20230602111622.swtxhn6lu2qwgrwq@techsingularity.net> References: <20230515113344.6869-1-mgorman@techsingularity.net> <20230515113344.6869-4-mgorman@techsingularity.net> <20230529103342.esek6r5fvmft2nky@techsingularity.net> <6695b7e5-9fa5-fae8-8a66-cc5985b0baaf@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <6695b7e5-9fa5-fae8-8a66-cc5985b0baaf@suse.cz> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 29, 2023 at 02:43:48PM +0200, Vlastimil Babka wrote: > On 5/29/23 12:33, Mel Gorman wrote: > > On Thu, May 25, 2023 at 03:37:43PM +0200, Vlastimil Babka wrote: > >> On 5/15/23 13:33, Mel Gorman wrote: > >> > isolate_migratepages_block should mark a pageblock as skip if scanning > >> > started on an aligned pageblock boundary but it only updates the skip > >> > flag if the first migration candidate is also aligned. Tracing during > >> > a compaction stress load (mmtests: workload-usemem-stress-numa-compact) > >> > that many pageblocks are not marked skip causing excessive scanning of > >> > blocks that had been recently checked. Update pageblock skip based on > >> > "valid_page" which is set if scanning started on a pageblock boundary. > >> > > >> > Signed-off-by: Mel Gorman > >> > >> I wonder if this has an unintended side-effect that if we resume > >> isolate_migratepages_block() of a partially compacted pageblock to finish > >> it, test_and_set_skip() will now tell us to abort, because we already set > >> the skip bit in the previous call. This would include the > >> cc->finish_pageblock rescan cases. > >> > >> So unless I miss something that already prevents that, I agree we should not > >> tie setting the skip bit to pageblock_aligned(pfn), but maybe if we are not > >> pageblock aligned, we should ignore the already-set skip bit, as it was most > >> likely being set by us in the previous iteration and should not prevent us > >> from finishing the pageblock? > >> > > > > Hmm, I think you're right. While it should not hit the original bug, > > migration candidates are missed until the next compaction scan which > > could be tricky to detect. Something like this as a separate patch? > > Build tested only but the intent is for an unaligned start to set the skip > > bet if already unset but otherwise complete the scan. Like earlier fixes, > > this might overscan some pageblocks in a given context but we are probably > > hitting the limits on how compaction can run efficiently in the current > > scheme without causing other side-effects :( > > Yeah that should work! I think it should be even folded to 3/4 but if you > want separate, fine too. > I was not happy with the test results so limited the scope of the patch which performed much better both in terms of absolute performance and compaction activity. Are you still ok with this version? Thanks --8<-- mm: compaction: Update pageblock skip when first migration candidate is not at the start -fix Vlastimil Babka pointed out the following problem with mm-compaction-update-pageblock-skip-when-first-migration-candidate-is-not-at-the-start.patch I wonder if this has an unintended side-effect that if we resume isolate_migratepages_block() of a partially compacted pageblock to finish it, test_and_set_skip() will now tell us to abort, because we already set the skip bit in the previous call. This would include the cc->finish_pageblock rescan cases. He is correct and a partial rescan as implemented in "mm, compaction: finish pageblocks on complete migration failure" would abort prematurely. Test and set the skip bit when acquiring "exclusive access" to a pageblock for migration but only abort if the calling context is rescanning to finish a pageblock. This is a fix for the mmotm patch mm-compaction-update-pageblock-skip-when-first-migration-candidate-is-not-at-the-start.patch Signed-off-by: Mel Gorman --- mm/compaction.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mm/compaction.c b/mm/compaction.c index 91af6a8b7a98..300aa968a0cf 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -1069,11 +1069,17 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn, lruvec_memcg_debug(lruvec, page_folio(page)); - /* Try get exclusive access under lock */ + /* + * Try get exclusive access under lock. If marked for + * skip, the scan is aborted unless the current context + * is a rescan to reach the end of the pageblock. + */ if (!skip_updated && valid_page) { skip_updated = true; - if (test_and_set_skip(cc, valid_page)) + if (test_and_set_skip(cc, valid_page) && + !cc->finish_pageblock) { goto isolate_abort; + } } /*