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 X-Spam-Level: X-Spam-Status: No, score=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49A98C433DB for ; Tue, 19 Jan 2021 19:26:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BF1BE23104 for ; Tue, 19 Jan 2021 19:26:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF1BE23104 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E4F7E6B0005; Tue, 19 Jan 2021 14:26:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E020F6B0006; Tue, 19 Jan 2021 14:26:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEF516B0007; Tue, 19 Jan 2021 14:26:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id B69E96B0005 for ; Tue, 19 Jan 2021 14:26:14 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7F5608249980 for ; Tue, 19 Jan 2021 19:26:14 +0000 (UTC) X-FDA: 77723505468.09.cap72_0a165f027554 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 64E40180AD801 for ; Tue, 19 Jan 2021 19:26:14 +0000 (UTC) X-HE-Tag: cap72_0a165f027554 X-Filterd-Recvd-Size: 6052 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Tue, 19 Jan 2021 19:26:13 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id g15so13572578pgu.9 for ; Tue, 19 Jan 2021 11:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=hfjS8PpIK8Sw4H2BcFdwSk9imrJFBiUObKqAE346rrk=; b=jyZa03UY8jzWno2ByRrYjgjIuxfrx8l6GP0hi8fyQo1ibeyOebB//A/mTKgQk8fLOk kV3jtIUFrA5uLcVGBtVIXP/+sM51GSwpXGMHSIXIQLkJ9xojm+qZNkDcYruKKsrO/8Fi 1ZXeflrRW7G3tUdtxoKWm0qaXcR0gPonGzp2DvuY/XlYsRflR2P19m1xaEwXAtWe6LJw uAkCj5qCL7hdEl2V4MwSj1idaEwSL2s8fViYo18/Lqk7Z612cms7cyZhI8k7bLYoEzQz VB3ResK/cl0l4jjet8E6r1hopiVM9BlmBuMjAABJJZBcwcaFJX4TzDvK4ddji7zbZwnL tHDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=hfjS8PpIK8Sw4H2BcFdwSk9imrJFBiUObKqAE346rrk=; b=bNGqrlHIJCW+3u6XpyQuBTFdIlfYqfG9wK/JL6XcfE27aoWr2YDgecG3yna9LKFta3 G2VhcI98XezUcqes+SihZSqD9fwYugNtF40NjW7s+/cyR1GugvZfu4/OkhsgaT9trdSr WP6kyUVTiMiO8evHWOV2w3bP8+0zr8+7Ph9gFchu0HaqEkmqlC8dqDzre9J6Z3mplhvA lSwgO833TrRaSOX5YhzuTEWAF1gC9EKG1jCWg+Y2J7xj6+ZhJki5qg2F9cQPFYmmafvf d/330DbPHanOGHxreSkoWiOR8Aheyv1iWJo7y2EMkioOJ652QzIUbj0xfGUdSDg2X3ai ldnA== X-Gm-Message-State: AOAM5306pCXrP3UOjrAhNwHUD+nFXumnkzW3oilzuTNxxrPIEofoHVVh rmWwQI/SHuTB5PTjLVL6LVJglg== X-Google-Smtp-Source: ABdhPJzQwpiDV5HQytZYjQWGdyI9tq13ne04cT1sfU9a98D/zozIZ7EUoNl+9+wMtJrdPfxxmr1q6Q== X-Received: by 2002:a63:1b1e:: with SMTP id b30mr5791504pgb.421.1611084370066; Tue, 19 Jan 2021 11:26:10 -0800 (PST) Received: from [2620:15c:17:3:4a0f:cfff:fe51:6667] ([2620:15c:17:3:4a0f:cfff:fe51:6667]) by smtp.gmail.com with ESMTPSA id a9sm19569815pfn.178.2021.01.19.11.26.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jan 2021 11:26:09 -0800 (PST) Date: Tue, 19 Jan 2021 11:26:08 -0800 (PST) From: David Rientjes To: Charan Teja Reddy cc: akpm@linux-foundation.org, vbabka@suse.cz, mhocko@suse.com, khalid.aziz@oracle.com, ngupta@nitingupta.dev, vinmenon@codeaurora.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V3] mm/compaction: correct deferral logic for proactive compaction In-Reply-To: <1610989938-31374-1-git-send-email-charante@codeaurora.org> Message-ID: References: <1610989938-31374-1-git-send-email-charante@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Mon, 18 Jan 2021, Charan Teja Reddy wrote: > should_proactive_compact_node() returns true when sum of the > weighted fragmentation score of all the zones in the node is greater > than the wmark_high of compaction, which then triggers the proactive > compaction that operates on the individual zones of the node. But > proactive compaction runs on the zone only when its weighted > fragmentation score is greater than wmark_low(=wmark_high - 10). > > This means that the sum of the weighted fragmentation scores of all the > zones can exceed the wmark_high but individual weighted fragmentation > zone scores can still be less than wmark_low which makes the unnecessary > trigger of the proactive compaction only to return doing nothing. > > Issue with the return of proactive compaction with out even trying is > its deferral. It is simply deferred for 1 << COMPACT_MAX_DEFER_SHIFT if > the scores across the proactive compaction is same, thinking that > compaction didn't make any progress but in reality it didn't even try. Isn't this an issue in deferred compaction as well? It seems like deferred compaction should check that work was actually performed before deferring subsequent calls to compaction. In other words, I don't believe deferred compaction is intended to avoid checks to determine if compaction is worth it; it should only defer *additional* work that was not productive. Thoughts? > With the delay between successive retries for proactive compaction is > 500msec, it can result into the deferral for ~30sec with out even trying > the proactive compaction. > > Test scenario is that: compaction_proactiveness=50 thus the wmark_low = > 50 and wmark_high = 60. System have 2 zones(Normal and Movable) with > sizes 5GB and 6GB respectively. After opening some apps on the android, > the weighted fragmentation scores of these zones are 47 and 49 > respectively. Since the sum of these fragmentation scores are above the > wmark_high which triggers the proactive compaction and there since the > individual zones weighted fragmentation scores are below wmark_low, it > returns without trying the proactive compaction. As a result the > weighted fragmentation scores of the zones are still 47 and 49 which > makes the existing logic to defer the compaction thinking that > noprogress is made across the compaction. > > Fix this by checking just zone fragmentation score, not the weighted, in > __compact_finished() and use the zones weighted fragmentation score in > fragmentation_score_node(). In the test case above, If the weighted > average of is above wmark_high, then individual score (not adjusted) of > atleast one zone has to be above wmark_high. Thus it avoids the > unnecessary trigger and deferrals of the proactive compaction. > > Fix-suggested-by: Vlastimil Babka Suggested-by > Signed-off-by: Charan Teja Reddy Acked-by: David Rientjes