Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2144381pxb; Mon, 18 Jan 2021 09:17:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHi4/l9Gq+8WNepe8wV/sTuuFRmehGRrbD7dzht0pT3js+Nck2FFzP5a+myuOuJzVBR8IO X-Received: by 2002:aa7:d489:: with SMTP id b9mr384471edr.374.1610990274836; Mon, 18 Jan 2021 09:17:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610990274; cv=none; d=google.com; s=arc-20160816; b=uUBq7KaEtxjjU5v5NjPEOOqWhhuZhENkJ7L8gwub7E1F0IIvMcfwU4IFGrBYm6YrGi dLk4vU/waofVUjZJckAqKknImO94DhVRe85Un3MHCGmLL8SyK/XGZJ89xdrm6RS+GA27 lyCCy6vgEZiXi8ZNynGkF160ERdud8fesZyIX/ZM4WBMGcDKGkazBantsuCWFt4dWqPJ DQtbsBX04zJ1dKHdLS7Ub2dBZIoHTBKrmvwU6tCNEtI3cjFPiG/rycy0m6wye4rHFey/ ugLPd8HtV3RkybHqHMbBcVBqQZUtlCTMTv+9Eb6Dw4u/+Elhlzko5vLCNyOrRIl0dsUo 3Uog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from:dmarc-filter :sender:dkim-signature; bh=7N0AL8N+d/LCg3DbSCNYLJGazZNXw3CzCrYyrHMBb6E=; b=MD6+Xbn/O6/1l+jX9m5gH5BusNNSjacmjlZ2DQEFv1NiKV0lU2+J1rraulkT3BDsTK 1wWyOn60Dm19lc9vClpafC74XnIAmxFMl7ATY6WBOqO9laJoTunKAOKfUEYHPBQHByZF vC1kWW7ttmrj6T6RJeuEBQD5NKNShGu/KLFmqawZPdkQFMhwX79/cXjlobVcnIbKzg6/ Z8f+2TCIQV0VQYfkVXOJ2VDt4mYlC3NclenDsP8WIjWiqvXdmYp9YSkA3QY2LOn26Jdc V0Neq3zWlefqnOZeQA6gvM5rFOlxLdaIrTuat7KJpSnfAT37DH+nZQlJNdhAyZiLTDFn +y1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=RT+UTL1c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f13si3776355edx.272.2021.01.18.09.17.29; Mon, 18 Jan 2021 09:17:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=RT+UTL1c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406888AbhARROK (ORCPT + 99 others); Mon, 18 Jan 2021 12:14:10 -0500 Received: from so254-31.mailgun.net ([198.61.254.31]:35615 "EHLO so254-31.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406991AbhARRNg (ORCPT ); Mon, 18 Jan 2021 12:13:36 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1610989994; h=Message-Id: Date: Subject: Cc: To: From: Sender; bh=7N0AL8N+d/LCg3DbSCNYLJGazZNXw3CzCrYyrHMBb6E=; b=RT+UTL1c0dQW2lv/vms6s/mmai+4llU88rAnrYlI0Rd7dVOQN8JzK8d9WgH+fY5TSkX318Yp 27lpSxX/tPJ3WCbYNGYnLguynC3N5suplov4f8gMpqvwcDL38Vgbu2k5LNMPALUgqMfNKARK v6DLgIsNimIeJNrbRJtBSM9j3uI= X-Mailgun-Sending-Ip: 198.61.254.31 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n02.prod.us-west-2.postgun.com with SMTP id 6005c188859d74370dc4d781 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 18 Jan 2021 17:12:40 GMT Sender: charante=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 1AD40C43461; Mon, 18 Jan 2021 17:12:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00,SPF_FAIL, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from charante-linux.qualcomm.com (unknown [202.46.22.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: charante) by smtp.codeaurora.org (Postfix) with ESMTPSA id DF24AC433CA; Mon, 18 Jan 2021 17:12:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org DF24AC433CA Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=charante@codeaurora.org From: Charan Teja Reddy To: akpm@linux-foundation.org, vbabka@suse.cz, mhocko@suse.com, khalid.aziz@oracle.com, ngupta@nitingupta.dev, vinmenon@codeaurora.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Charan Teja Reddy Subject: [PATCH V3] mm/compaction: correct deferral logic for proactive compaction Date: Mon, 18 Jan 2021 22:42:18 +0530 Message-Id: <1610989938-31374-1-git-send-email-charante@codeaurora.org> X-Mailer: git-send-email 2.7.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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 Signed-off-by: Charan Teja Reddy --- Changes in V3: Addressed suggestions from Vlastimil Changes in V2: https://lore.kernel.org/patchwork/patch/1366862/ Changes in V1: https://lore.kernel.org/patchwork/patch/1364646/ mm/compaction.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/mm/compaction.c b/mm/compaction.c index e5acb97..ccddb3a 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -1925,20 +1925,28 @@ static bool kswapd_is_running(pg_data_t *pgdat) /* * A zone's fragmentation score is the external fragmentation wrt to the - * COMPACTION_HPAGE_ORDER scaled by the zone's size. It returns a value - * in the range [0, 100]. + * COMPACTION_HPAGE_ORDER. It returns a value in the range [0, 100]. + */ +static unsigned int fragmentation_score_zone(struct zone *zone) +{ + return extfrag_for_order(zone, COMPACTION_HPAGE_ORDER); +} + +/* + * A weighted zone's fragmentation score is the external fragmentation + * wrt to the COMPACTION_HPAGE_ORDER scaled by the zone's size. It + * returns a value in the range [0, 100]. * * The scaling factor ensures that proactive compaction focuses on larger * zones like ZONE_NORMAL, rather than smaller, specialized zones like * ZONE_DMA32. For smaller zones, the score value remains close to zero, * and thus never exceeds the high threshold for proactive compaction. */ -static unsigned int fragmentation_score_zone(struct zone *zone) +static unsigned int fragmentation_score_zone_weighted(struct zone *zone) { unsigned long score; - score = zone->present_pages * - extfrag_for_order(zone, COMPACTION_HPAGE_ORDER); + score = zone->present_pages * fragmentation_score_zone(zone); return div64_ul(score, zone->zone_pgdat->node_present_pages + 1); } @@ -1958,7 +1966,7 @@ static unsigned int fragmentation_score_node(pg_data_t *pgdat) struct zone *zone; zone = &pgdat->node_zones[zoneid]; - score += fragmentation_score_zone(zone); + score += fragmentation_score_zone_weighted(zone); } return score; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation